Dev - Thread with TX marked for rollback cannot start TX

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Dev - Thread with TX marked for rollback cannot start TX

Eilebrecht, Karl  (Key-Work)

Hi,

 

it seems to me that there is a little bug in TransactionUtil.

 

TransactionUtil does not allow a thread with a transaction assigned

that has a state other than “STATUS_ACTIVE” (i.e. marked for rollback)

to be suspended.

 

One should be able to reproduce this by calling getNextSeqId() (several times, at least ten) after a persistence

call failed (i.e. insert, pk-constraint violation) within the try-catch-block, because the sequence behind getNextSeqId() uses its

own transaction when running out of ids (suspend->begin->commit->resume) to get a new bunch of ids.

You should see an exception that a transaction could not be started because the currently

running is marked for rollback (old one was NOT suspended).

 

A Look at the implementation shows that the problem is almost the same like

the “transaction start stamp problem” I reported some time ago.

The rollbackcause is not implemented as a stack but as a variable.

Due to this limitation TransactionUtil must do the following check in the suspend-Method

not to get in real trouble:

if (TransactionUtil.getStatus() == TransactionUtil.STATUS_ACTIVE) {

 

Solution would be to implement the rollbackcause-management as a stack and change

that line to:

if (TransactionUtil.getStatus() != TransactionUtil.STATUS_NO_TRANSACTION) {

 

A workaround (without changing TransactionUtil) for the meantime is to put the operation to be executed in

a new Transaction into a new Thread and wait for completion.

If this is only done in the case of rollback the time spent for thread creation should not matter.

 

Regards.

Karl

 

BTW: GenericDAO has some methods “pretending” to do a rollback by calling SqlProcessor.rollback(). But this is only blur, because the internal code will not be reached, because the connection is null, because bDeleteConnection is true, because getConnection sets this flag always to true because the sky is blue …; The rollback (or mark for rollback) is done by the methods of GenericDelegator.

 

 

 

 

_____________________________________________

 

Karl Eilebrecht
Key-Work Consulting GmbH

 

Kriegsstr. 100
76133 Karlsruhe
Germany
+49-721-78203-277
______________________________________________

 


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Dev - Jira 370 (CLONE -I18n of POS : changing name of xui.properties)

Jacques Le Roux
Administrator

Hi,

Please might someone with rights on guiapp component throw a glance at this issue ? It's really easy to do and will clean my brain and eclipse project. Though as guiapp component is mainly related to XUI hence POS perhaps it will be easier to allow me writing right as I expect to work on it.

Jacques


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev