On 06/22/2012 09:32 AM, Christian Romberg wrote:
> On Thu, Jun 21, 2012 at 10:49 AM, Jonathan Halliday
> <jonathan.halliday_at_redhat.com <mailto:jonathan.halliday_at_redhat.com>> wrote:
>
> I'm averse to anything that requires additional bytes to be forced
> to disk on each transaction. It's not necessary for obtaining the
> in-doubt list from an RM. For that you need only one XAResource for
> the entire RM, not one per tx.
>
>
> 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. That seems
modest for a JNDI name, much less a serialized XAResource. Not that it
matters - I'm fine with the idea that on an HDD based log the sequential
write of some additional bytes is dominated by the sync cost anyhow and
thus of less concern, although assembling those bytes by object
serialization still aint cheap.
But I'm still not happy requiring the additional log bytes. Supporting
the option, sure. But it's going to hurt SSD based logs and network
memory replication based logs, which are sensitive to block size and
packet size respectively. For that matter it's going to hurt memristor
or battery backed RAM logs, both of which we can expect to see in the
lifetime of the JTA spec.
We need spec changes that will make additional information available to
the TM, but leave it up to the TM implementation how best to utilise
that information.
BTW your logs are not going to be self contained even with the
additional bytes. If you serialize an object, you need the class file
(and a suitable classloader to process it) at recovery time. That's not
trivial in the complex classloading environments of a modular app
server. If you serialize the JNDI name, you need the datasource deployed
at the same JNDI location at recovery time - config changes to rewire a
name to RM relationship can be disastrous. Oh, and watch out for the
default character set differing on the log writing and recovery nodes -
that one causes no end of fun unless you write the charset encoding data
into the logs along with the string.
> interface AnnotatedXAResource extends XAResource {
> byte[] getJNDIName()
> }
>
> What type of object should the JNDI name refer to?
The byte[] is a serialized String. It's providing diagnostic and
identity information only, not an object that actually offers methods
useful at recovery time. That's what the callback interface is for:
interface XARecovery {
XAResource getXAResource(); // to be called by the TM's recovery system.
}
except of course that should actually be
interface XARecovery {
AnnotatedXAResource getAnnotatedXAResource(); // to be called by the
TM's recovery system.
}
the point being, it allows you to validate that a log record you have
belongs to a given RM, even if that RM's in-doubt list does not contain it:
byte[] recoveryIdentity = xaRecovery.getAnnotatedXAResource().getJNDIName();
byte[] logIdentity = logfile.getTxRecord().getJNDIName();
if(recoveryIdentity.equals(logIdentity)) {
// we know which RM the branch belongs to
}
so if the in-doubt list from recover() does not contain it, you can
safely dispose of it.
Jonathan.
--
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)