Mahalo endless loop on prepareAndCommit

[Guy Korland <Gu...@gigaspaces.com>]

Hi,

 

We found out that TransactionManager.commit(long timeout) might stack
forever even if we set a timeout.

 

It seems like the following code on TxnManagerTransaction is the source
of it (line 680):

 

  if ((job instanceof PrepareJob) ||

 

                      (job instanceof PrepareAndCommitJob)) {

 

                        try {

 

 Line 680:                                              if

(job.isCompleted(Long.MAX_VALUE)) {

 

                                    result = (Integer)
job.computeResult();

 

 

Do you have any suggestions?

 

Thanks,

Guy

 

Re: Mahalo endless loop on prepareAndCommit

[Robert Resendes <Ro...@Sun.COM>]

Guy Korland wrote:
> Hi,
> 
>  
> 
> We found out that TransactionManager.commit(long timeout) might stack
> forever even if we set a timeout.
> 
>  
> 
> It seems like the following code on TxnManagerTransaction is the source
> of it (line 680):
> 
>  
> 
>   if ((job instanceof PrepareJob) ||
> 
>  
> 
>                       (job instanceof PrepareAndCommitJob)) {
> 
>  
> 
>                         try {
> 
>  
> 
>  Line 680:                                              if
> 
> (job.isCompleted(Long.MAX_VALUE)) {
> 
>  
> 
>                                     result = (Integer)
> job.computeResult();
> 
>  
> 
>  
> 
> Do you have any suggestions?
[Response carried over from 
http://archives.java.sun.com/cgi-bin/wa?A2=ind0805&L=JINI-USERS&T=0&F=&S=&P=3649]

Without more details, I can only guess as to what's happening. One 
possibility is that you have a "misbehaving" transaction participant 
that is taking a long time to respond to the "prepare" part of the 
two-phase commit protocol. If so, then here's what would happen:

- client calls commit() with or without a timeout[1]
- The transaction manager creates a PrepareJob[2] that will "ask" each 
participant whether or not it can complete the transaction
- The transaction manager will wait until the PrepareJob provides an 
answer before continuing (i.e. abort or commit).

The PrepareJob attempt to call "prepare" on each participant. If any of 
those attempts are hanging, then the manager will hang as well (because 
it needs an answer).

Hopefully, this helps, but if it doesn't, then please send more details 
regarding what you are doing and seeing.

You might also consider sending any follow-up messages to the River User 
List (see http://incubator.apache.org/river/RIVER/mailing-lists.html) 
because all the new development effort has shifted (from Sun) to that 
project under the Apache organization.


Notes:

[1] Note the timeout parameter only states how long the client is 
willing to wait for the manager to notify the participants of the 
transaction's outcome (i.e. abort/commit). The timeout only applies 
after the state of the transaction is determined. See 
http://java.sun.com/products/jini/2.0/doc/specs/html/txn-spec.html#7224.

[2] There is also a PrepareAndCommitJob that optimizes for the single 
participant case, but the explanation is similar.