Typically the idea with transactions is that you have one or more
groups of operations that need to succeed or fail all together. With
OFBiz the easiest way to do this is to have each group of operations
represented by a service (that may or may not call sub-services) and
then setup your transaction settings on the services however is
needed, such as using the require-new-transaction attribute to suspend/
resume any existing transaction to allow the operations to commit or
rollback independent of the other transaction.
If you want every single call to the entity engine to run separately,
you could try to set use-transaction attributes to false, but if
anything with a transaction calls your service there may still be a
transaction in place and that would mess things up. It's better to
explicitly demarcate things.
-David
On Nov 21, 2009, at 6:44 PM, Ruth Hoffman wrote:
Hi David:
Sorry, I meant: How do I guarantee that each write is committed to
disk when I have a series of delegator.save or delegator.create
calls? I want each write to be committed (as a separate transaction
I suppose) and then, if there is also a service call after all these
writes, how do I ensure that a failure in the service call does not
roll back only some of the previous writes.
Ruth
David E Jones wrote:
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.
