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 Kriegsstr. 100 _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
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 |
Free forum by Nabble | Edit this page |