What does it mean to "completely control reads/writes"?
-David
On Nov 21, 2009, at 1:32 PM, Ruth Hoffman wrote:
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.
