Dev - Resumed Transactions get a new Start Timestamp

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

Dev - Resumed Transactions get a new Start Timestamp

Eilebrecht, Karl  (Key-Work)

Hi,

 

I’m a newbie here, working some months with ofbiz now.

While programming a full-db-access-log for our ofbiz-instance

I stumbled across a little bug (I think) in the transaction handling of ofbiz.

 

Situation:

A transaction TX1 has been suspended by a Thread.

This thread uses now a new Transaction TX2 to do something and ends this transaction.

After that the Thread resumes TX1 and goes on.

At this time TX1 has a no start time stamp. The start time stamp will be set to NOW during the

next call of the method getTransactionStartStamp() – probably unexpected by the caller.

 

When does this occure?

Usually you don’t see this, because suspending a transaction is rare in ofbiz.

But there is one common example:

When the bank behind getNextSeqId()-Id runs out of Ids, it gets filled using a new

transaction (suspending the original one).

If you store two entities in this transaction before and after the filling of the bank they

will get two different CREATED_TX_STAMP values.

 

My employer is currently not contributing to ofbiz yet (planned for autumn, maybe …)

 

Nevertheless I found a solution and changed the class TransactionUtil.

Should I post the changes here, or is there someone just caring of the transaction handling things?

 

Regards.

Karl

 

 

_____________________________________________

 

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
|

Re: Dev - Resumed Transactions get a new Start Timestamp

David E. Jones

That is an interesting issue. It might be good to have it fixed, but  
the main thing that uses these time stamps is the EntitySync stuff,  
and for that breaking up a transaction in this way to get the data  
moved over in a good order is not actually a bad thing...

The best thing to do with this sort of thing is to create an issue in  
Jira for this (you'll need to sign up for an account there, but  
that's quick and easy), and then attach your patch to it. The Jira  
server is at:

http://jira.ofbiz.org

-David


On Feb 16, 2006, at 7:49 AM, Eilebrecht, Karl ((Key-Work)) wrote:

> Hi,
>
>
>
> I’m a newbie here, working some months with ofbiz now.
>
> While programming a full-db-access-log for our ofbiz-instance
>
> I stumbled across a little bug (I think) in the transaction  
> handling of ofbiz.
>
>
>
> Situation:
>
> A transaction TX1 has been suspended by a Thread.
>
> This thread uses now a new Transaction TX2 to do something and ends  
> this transaction.
>
> After that the Thread resumes TX1 and goes on.
>
> At this time TX1 has a no start time stamp. The start time stamp  
> will be set to NOW during the
>
> next call of the method getTransactionStartStamp() – probably  
> unexpected by the caller.
>
>
>
> When does this occure?
>
> Usually you don’t see this, because suspending a transaction is  
> rare in ofbiz.
>
> But there is one common example:
>
> When the bank behind getNextSeqId()-Id runs out of Ids, it gets  
> filled using a new
>
> transaction (suspending the original one).
>
> If you store two entities in this transaction before and after the  
> filling of the bank they
>
> will get two different CREATED_TX_STAMP values.
>
>
>
> My employer is currently not contributing to ofbiz yet (planned for  
> autumn, maybe …)
>
>
>
> Nevertheless I found a solution and changed the class TransactionUtil.
>
> Should I post the changes here, or is there someone just caring of  
> the transaction handling things?
>
>
>
> Regards.
>
> Karl
>
>
>
>
>
> _____________________________________________
>
>
>
> 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

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