On 06/22/2012 01:22 PM, Christian Romberg wrote:
> Hi Jonathan,
>
> On Fri, Jun 22, 2012 at 12:20 PM, Jonathan Halliday
> <jonathan.halliday_at_redhat.com <mailto:jonathan.halliday_at_redhat.com>> wrote:
>
>
> On 06/22/2012 09:32 AM, Christian Romberg wrote:
>
>
>
> I understand your concerns, however I have a different view on those
> additional bytes, I think the transaction log should be as
> self-contained as possible and
> an additional 20-40 byte per transaction don't harm IMO.
>
>
> I'm not sure where you're getting the 20-40 bytes size from.
>
>
> this is an estimate of all the information we would need to bootstrap
> our resource manager
> to be able to provide an XAResource for recovery:
>
> 4-8 byte magic number, to know, that it is our data, 2 byte version
> information, 20-30 ASCII-7 characters for the database URL
>
> Assuming a registry of resource managers, there is no need for any class
> information.
I thought you were of the opinion that the transaction log should be as
self-contained as possible? :-)
> Also this information is static and the same for all XAResource
> instances for a particular database, so it's calculated once and reused.
>
> On a second thought, this even allows to compress the data to a single
> byte only:
>
> The TransactionManager could maintain a map of local 1-byte identifiers
> to recovery infos in the head of it's log file like this.
>
> HEAD
> --------
> ....
> 1 -> byte[] (from e.g. us for database "versant:db1_at_machine")
> 2 -> byte[] (from e.g. Oracle to database so-and-so ...)
sure, lookup table based data compression is older than I am. But
internals of the log format have no place in the spec, it's something
that should be left to the implementation.
BTW how do you handle authentication credentials needed to reattach to
the database? The url/name is not the only input you need for that
operation in most cases. Part of the reason I favour a registration API
for providing the recovery system with an XAReosurce instance is that it
leaves that up to the container rather than forcing the TM to duplicate
much of the functionality already found elsewhere.
> byte[] logIdentity = logfile.getTxRecord(). getJNDIName();
>
> But we don't have a real JNDI name, of course we could provide some
> opaque identifier for the logfile,
> but I think we should avoid the term JNDI here.
ok. Our internal API actually uses the term EISName since the RM is not
always a database, but given your feelings on the JCA spec I'm guessing
you're not going to be a big fan of that choice either. Care to pick
something else?
The point I'm trying to capture in the name is that it should be usable
as a key into whatever configuration mechanism the environment is using.
An administrator reading it in the logs should be easily able to
determine which RM instance is the source. JNDI name is useful for that
in most Java EE app servers, which is the dominant use case.
Jonathan.
--
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)