Hi Kumaraswamy:
Thanks for the link info. I guess what I'm saying is why would an ECA
effect a previous database write and then read (a transaction) that
appeared to be committed? I thought that a delegator.store operation
wrote a record to the database and a delegator.findAll where the cache
flag was set to false, read from the database. Are you saying that
perhaps this is not the case when there is a service with an ECA defined
is called inline with my other code?
TIA
Ruth
Kumaraswamy nandipati wrote:
Hi Ruth,
http://ofbiz.apache.org/docs/services.html#ECAs
ECA definition replicates what I mean.
On Sat, Nov 21, 2009 at 6:54 PM, Ruth Hoffman <[email protected]> wrote:
Hi Kumaraswamy:
I'm not sure I understand your comment. Would you mind elaborating?
Regards,
Ruth
Kumaraswamy nandipati wrote:
Hi Ruth,
I am suspecting that ECAs doing this. For ECAs we can define before/after
Transaction commit/rollback(Its just my suspect only. But I didn't try for
this).
On Fri, Nov 20, 2009 at 6:25 PM, Ruth Hoffman <[email protected]>
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.
