There isn't enough detail in here to say what might be wrong, but it
sounds like it may simply be a misunderstanding about how transaction
demarcation and transaction isolation work (for databases in general,
and also in OFBiz). For example, during a transaction if you update a
record you should expect to see that record if you do a find in the
same transaction; and if you do a find in a different transaction
whether you see the record or not depends entirely on the transaction
isolation level that you have configured. Some transaction isolation
levels do result in "phantom reads".
As far as the Entity Engine goes it doesn't really do anything with
transactions. When you run an EE operation it will run inside whatever
transaction is already in place. If there is no transaction in place
most operations won't do anything, but a few that often require a
transaction will begin one and then commit it before it's done.
The main place to manage transaction in OFBiz is through the service
engine, and there are a few attributes on a service definition to use
a transaction or not (will use an existing one or begin/commit/
rollback a new one), and also whether to require a new transaction
(always does a begin/commit/rollback, suspending any existing
transaction that might exist). How to use these depends on how you
want to group operations to succeed or fail together.
-David
On Nov 20, 2009, at 5:55 AM, Ruth Hoffman wrote:
Hi Karthik:
I was just getting ready to write a similar email to the list. I've
noticed this also - but only in the 9.4x releases. In my case some
of the database writes are committed and "stick" while some do not.
Here's my situation:
I have a custom application with 5 separate database writes
(delegator.store or delegator.create) operations followed by an
service call to one of the sendMail services and then a call to
another delegator.store operation. If the sendMail fails, several of
my 5 separate database writes are not committed. Further, if I do a
read of the database (delegator.findOne) after one of the writes
that are not committed, I get a record returned with my data (I can
see this by writing a debug statement.) So, I wonder what is going
on? Do I need to actually force each of these writes to the physical
data source through some other action aside from the
delegator.store? I tried writing each database write in a separate
try/catch as I though that was the default transaction boundary.
Then I put each database write in a separate service and made a
service call to each write - hoping that the service engine would
somehow force the transaction to commit. But nothing works. In each
case I get the same results: some data is written and then I get the
"Transaction Timed Out" error.
Any suggestions would be greatly appreciated. The bad thing about
this situation is that it does write some of the data to the
database but not all of it. So I have "widowed and orphaned" data.
Any Entity Engine experts out there with some advice?
Regards,
Ruth
karthik Ofbiz wrote:
Hi all,
We are using Ofbiz for running our web sites. Now a days we are
seeing few
problems with the transactions happening in the system.
Whenever any service is called, and if it's execution is failed
because of
any database exceptions then the transaction is not completely
rolling
back.The database exception I am seeing in "Transaction Timed out
Exception".
As a result we are not having complete data in the system
Any one Help me in this issue.
Thanks in advance and eagerly waiting for the reply.....
Regards,
Karthik Ramini.
