On 2001.06.27 10:55:10 -0400 Bill Burke wrote:
>
>
<snip>
> > >
> > > |
> > > |1. Start JBoss transaction
> > > |2. Access Entity1. A connection is grabbed from pool 1,
> > > |connection1.setIsolation(blah blah),
> > > |3. access entity2. A connection is created from pool 2,
> > > |connection2.setIsolation(blah blah)
> > > |4. End JBoss transaction. commit is called on connection 1 and
> > > connection
> > > |2.
> > > |
> > > |This should work, shouldn't it?
> > > |
> >
> > Well, maybe. To make this work, you require true xa capable drivers,
> and
> > you need to use real 2pc, not the fake stuff from jbosspool wrappers.
> The
> > wrapped drivers will give you 2 independent conncurrent transactions.
> >
>
> I don't know about you, but I'm happy with the fake XA that the jbosspool
> wrappers provide. Shouldn't it work 99.999% of the time?
>
> Bill
It depends how critical data integrity is to you. If you have only one
resource/pool, they work fine, because you only need 1pc. If you have more
than one resource/pool (as you are suggesting), then if the second "branch"
fails to commit, you are stuck with the first branch having committed, the
second rolled back ==> data integrity failure. If you can guarantee that
both transactions will commit when called (for instance deferring fk
constraints till end of transaction will not guarantee this), the only
thing you have to worry about is something crashing between commit branch1
and commit branch 2. I don't know if there is some way to detect this in
the logs, but your db would be in an inconsistent state, with no automatic
way of recovering. Whether this is a problem for you is another question,
but this is what xa/2pc addresses.
david jencks
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
