Hi Jonathan,
I agree, that extending XAResource or the enlistResource call are far
superior to what I have suggested, however IMO it would also mean
more work for all existing implementation. (Btw. I'm curious to know, how
many implementations, which have really seen
production use, are there at all?)
I could imagine, that all ResourceManagers in a system could be required to
register similar to e.g. either the mechanism used
for JDBC drivers or for different JPA implementations, and they could
implement something like this
interface Recovery {
XAResource getXAResource(byte[] recoveryInformation); //returns null,
if recoveryInformation is from a different implementation
}
XAResource could be extended as follows:
interface XAResource {
//...
byte[] getRecoveryInformation()
}
The result of getRecoveryInformation() would be opaque and stored in the
transaction log file of the transaction manager.
Each Resource Manager would be responsible to include all information it
needs in there.
Through the "resource manager registry" they could be probed later with
exactly this information and be required, to
determine, is it their information or that of a different resource manager.
If it's their information, they are required to return an XAResource
instance that can be used for recovery.
If they return null, the next registered resource manager is probed.
Regards,
Christian
On Wed, Jun 20, 2012 at 5:23 PM, Jonathan Halliday <
jonathan.halliday_at_redhat.com> wrote:
>
> On 06/20/2012 11:02 AM, Christian Romberg wrote:
>
> I suggest to mandate the following behavior for the transaction manager
>> when writing it's log file:
>>
>> "If the XAResource was acquired via a JNDI named pool or the XAResource
>> is serializable, the
>> transaction manager might store the JNDI name, or the serialized
>> XAResource in it's transaction
>> log file. If the XAResource was not acquired via a JNDI named pool and
>> is not serializable, an
>> exception will be thrown".
>>
>
> JNDI names present some fun issues for distributed environments, or even
> environments that changes over time. In practice they are more useful for
> providing additional information to recovery and for diagnostic log
> messages than for fully automated recovery. Extending XAResource or
> tx.enlistResource to support them is useful but insufficient IMO. Object
> serialization is far too slow to be attractive. An interface by which
> XAResources may be registered with the TM for recovery use is preferable,
> though getting something totally portable may require changes to the JCA
> spec too.
>
> Jonathan.
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
> (USA), Charlie Peters (USA)
>
--
Christian Romberg
Chief Engineer | Versant GmbH
(T) +49 40 60990-0
(F) +49 40 60990-113
(E) cromberg_at_versant.com
www.versant.com<http://www.google.com/url?q=http%3A%2F%2Fwww.versant.com%2F&sa=D&sntz=1&usg=AFrqEzeeEBc_gN_8mxtt8xDB0tjXDXQVlw>|
www.db4o.com<http://www.google.com/url?q=http%3A%2F%2Fwww.db4o.com%2F&sa=D&sntz=1&usg=AFrqEzdo3Q40RwKQPBtnPIuBYQd1diFxJQ>
--
Versant
GmbH is incorporated in Germany. Company registration number: HRB
54723, Amtsgericht Hamburg. Registered Office: Halenreie 42, 22359
Hamburg, Germany. Geschäftsführer: Bernhard Wöbker, Volker John
CONFIDENTIALITY
NOTICE: This e-mail message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential or
proprietary information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
immediately contact the sender by reply e-mail and destroy all copies of
the original message.