You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by karthik Ofbiz <ka...@gmail.com> on 2009/11/20 12:11:55 UTC
Regarding Transactions
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.
Re: Regarding Transactions
Posted by Ruth Hoffman <rh...@aesolves.com>.
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 <rh...@aesolves.com> 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 <rh...@aesolves.com>
>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>
Re: Regarding Transactions
Posted by Kumaraswamy nandipati <ku...@ecomzera.com>.
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 <rh...@aesolves.com> 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 <rh...@aesolves.com>
>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
--
Thanks,
Kumaraswamy.N
91-9866805250.
Re: Regarding Transactions
Posted by Ruth Hoffman <rh...@aesolves.com>.
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 <rh...@aesolves.com> 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.
>>>
>>>
>>>
>>>
>
>
>
Re: Regarding Transactions
Posted by Kumaraswamy nandipati <ku...@ecomzera.com>.
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 <rh...@aesolves.com> 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.
>>
>>
>>
>
--
Thanks,
Kumaraswamy.N
91-9866805250.
Re: Regarding Transactions
Posted by David E Jones <de...@me.com>.
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.
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: Regarding Transactions
Posted by Ruth Hoffman <rh...@aesolves.com>.
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.
>>>>>
>>>>>
>>>
>>>
>
>
Re: Regarding Transactions
Posted by David E Jones <de...@me.com>.
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.
>>>>
>>>>
>>
>>
Re: Regarding Transactions
Posted by Ruth Hoffman <rh...@aesolves.com>.
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.
>>>
>>>
>
>
Re: Regarding Transactions
Posted by David E Jones <de...@me.com>.
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.
>>
>>
Re: Regarding Transactions
Posted by Ruth Hoffman <rh...@aesolves.com>.
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.
>
>