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. |
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. > > |
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 <[hidden email]> 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. |
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 <[hidden email]> 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. >>> >>> >>> >>> > > > |
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 <[hidden email]> 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 <[hidden email]> >> 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. |
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 <[hidden email]> 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 <[hidden email]> >>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> > > > |
In reply to this post by Ruth Hoffman-2
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. >> >> |
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. >>> >>> > > |
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. >>>> >>>> >> >> |
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. >>>>> >>>>> >>> >>> > > |
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. >>>>>> >>>>>> >>>> >>>> >> >> |
Free forum by Nabble | Edit this page |