On Thu, 31 May 2001, Toby Allsopp wrote:
> On Wed, May 30, 2001 at 07:19:26PM -0400, Anatoly Akkerman wrote:
> >
> > Hello everybody
>
> Hello. I guess I should attempt to field this.
>
> > I am running into problems with JBoss pools and Tyrex. This time it is a
> > 2pc hueristic commit issue.
>
> Great. A wurble-munging wickety booger.
I guess I was not clear enough. Tyrex is a DTM from exolab.org which I
integrated with JBoss and committed into CVS a week ago. (check out
org.jboss.tm.plugins.tyrex)
The issue is using jboss pools in a distributed transaction (in my case,
I've split the Petstore into pieces and deployed on several JBoss servers
to test distributed transactions for my project)
I've experienced transaction rollbacks under certain deployment scenarious
and when I tracked down where they were coming from, it happened to be the
minerva module. The scenario is as follows:
3 jboss servers
server1: a bean initiates a transaction and in the context of this
transaction calls beans on server2 and server3
server2: bean accesses a local datasource (minerva-wrapped
cloudscape db) modifies some data
server3: bean accesses a local datasource (minerva-wrapped cloudscape
db) and modifies data
server1: tries to commit the transaction, causing commit on the
subtransactions in the server2 and server3 and their respective
datasources
(more below)
>
> > When Tyrex commits a distributed transaction in 2pc, it asks all the
> > subordinate transactions to commit which ask their local XAResources to
> > commit.
> >
> > Minerva on a commit call disassociates itself from the transaction (sets
> > current to null).
>
> Are you talking about Minerva's XADataSource implementation
> (org.jboss.pool.jdbc.xa.wrapper.XA*)?
>
Yes, indeed.
(more below)
> This implementation is just a wrapper for non-XA JDBC drivers so that they
> can participate in transactions managed by a JTA transaction manager. It
> doesn't magically give these drivers the ability to handle 2pc correctly.
>
> I'm not sure what scenario exactly you're testing, but if you're using the
> wrappers then you should not have more than one resource enlisted in the
> transaction.
>
> > Tyrex upon getting successful commits from the XAResources, being in 2pc
> > sets heuristic to COMMIT and asks the XAResources to forget() the
> > transaction.
>
> I don't understand what JTA is talking about with "heuristic" this and
> that. It seems like a mechanism for dealing with strange situations or
> something.
>
> What is Tyrex trying to achieve with this heuristic stuff? What do you
> mean by "sets heuristic to COMMIT"?
>
On a 2pc Tyrex DTM the originator transaction (sitting on server1) asks
its subordinate transactions (on server2 and server3) to commit.
The subordinate transactions (on server2 and server3) call commit() on
their datasources and return their votes to the main coordinator. The
coordinator based on the votes takes a heuristic decision on what to do
about the completion of this transaction. If there were no errors
reported, the TM decides to complete the commit heuristically. So, it does
not throw any exceptions, but tries to tell all the subordinates to
forget() the transaction. This indicated that the last request (commit())
was accepted by everybody and everybody can now forget about this
transaction.
So, it comes out that the XAResource should expect to see a
commit() followed by forget() in such a scenario.
Minerva code seems not to support this type of scenario. First, on a
commit() of minerva XAResource the current is set to null. And second,
even if we delay setting current to null till forget() is called,
forget() calls the underlying jdbc connection saying something about
transaction failing, which is not true in this particular case.
> > Minerva throws an exception because it already disassociated itself from
> > the transaction (i.e. current == null while id is not null). Also, minerva
> > assumes that the forget() is always called when a commit() or rollback()
> > have failed. Well, this is not really true, forget can get called during a
> > heuristic commit as in the case described above.
>
> This may well be a problem with Minerva/JBossPool, but the wrappers really
> aren't meant to handle anything complicated.
>
I am no JDBC/transactions guru, I've implemented the tyrex module and
planning to use it for my research, so if Minerva is inherently incapable
of handling these types of scenarios, I'll go ahead and get Oracle or
something that can handle it. I was just wondering if minerva can be
patched up to support my scenario as well.
> > Anyone can suggest to me where I could find out what is the correct
> > semantics of the API? I've tried the jta spec but could not see anything
> > conclusive. Any idea how minerva should handle this properly?
>
> The JTA spec is all I have to go on. It refers to the X/Open XA spec, but
> that's not free.
>
> > Also, as a side issue, the jta spec says that the XAResources should
> > support sharing (3.4.6) which seems to be lacking from the minerva (JBoss
> > pool) implementation? Am I making a mistake here?
>
> You are correct, it's not supported. It's a wraper for JDBC connections,
> don't forget, not an actual XAResource implementation.
>
I can't forget something I did not really know :)
Again, I am quite new to this stuff.
> Toby.
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
Anatoly.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
