Hi David:
Thanks for this explanation. So, to completely control reads/writes
should I wrap each database call in a service and then set the
transaction isolation level within that service?
TIA
Ruth
David E Jones wrote:
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.
