• Post Reply Bookmark Topic Watch Topic
  • New Topic

Container Managed Transaction - Synchronization question

 
Gavin Rifkind
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


I have a enterprise bean which is using container managed transactions to access data in Oracle. The bean has 2 methods. Method1 writes an entry to table 1 and then does a lookup for a corresponding entry in table 2. Method2 writes an entry to table 2 and then does a lookup for a corresponding entry in table 1.

I have the rare occasion where the 2 methods are called so close together, that Method1 does the lookup on table 2, before Method2 has committed, and similarly Method2 does the lookup on table 1 before Method1 has committed.

I have thought about using isolation level of uncommitted reads. However I have 2 problems with that, firstly I have read somewhere that Oracle does not support uncommtted reads, and secondly this has the potential that I could match the entries twice, once in Method1 and once in Method2. This will be a problem for the application.

I would appreciate any suggestions about how to solve this problem.

Thanks
 
Ravi Kiran Va
Ranch Hand
Posts: 2234
Eclipse IDE Firefox Browser Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gavin , your question is no where related to Container Managed Transaction or any Transactions Related , question is purely related to calling of methods in a sequence of order , you need to anaylize why is this happeing ??

Are there any threads being created explicitly for calling of those methods ?? Or its only single Thread that does all this calling ??



 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In these rare occasions, why does the behaviour matter? I am guessing, if you have chosen read-committed transaction isolation, that this is how you would want it to behave, i.e. your business transaction is both the write and read? If its not, rather than swapping to read uncommitted (which you are right, Oracle does not support) would it not make more sense to change from a container managed transaction for this method to bean managed? Then you can commit before the read.
 
Gavin Rifkind
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Sturrock wrote:In these rare occasions, why does the behaviour matter? I am guessing, if you have chosen read-committed transaction isolation, that this is how you would want it to behave, i.e. your business transaction is both the write and read? If its not, rather than swapping to read uncommitted (which you are right, Oracle does not support) would it not make more sense to change from a container managed transaction for this method to bean managed? Then you can commit before the read.


Hi Paul, you are correct that the business transaction includes both the write and the read, as well as some other actions too. So container managed transaction is the correct choice, and even if I change to bean managed, the correct place for the commit is still after the read anyway.

However these rare occurrences when the methods are called almost at the same time, result in unmatched entries that require manual intervention. I was hoping to find a solution that would be able to match these entries without manual intervention.
Thanks for any further suggestions
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I hate to suggest it but it almost sounds like you may need pessimistic locking, that is unless you can think of a way to programatically spot "unmatched" entries, or change other logic to tolerate it? Pessimistic locking is to be avoided unless you really need it.

Not sure what "matching" denotes, but could you tolerate unmatched entries until the next transaction runs? i.e. transaction one and two run close together, leaving some data needing resolved. When transaction three comes along it picks this data up?
 
Gavin Rifkind
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Sturrock wrote:I hate to suggest it but it almost sounds like you may need pessimistic locking, that is unless you can think of a way to programatically spot "unmatched" entries, or change other logic to tolerate it? Pessimistic locking is to be avoided unless you really need it.


I don't understand how pessimistic locking will help, please can you explain.

I have thought of a way to programatically detect the unmatched entries, but I don't like it because it makes the assumption that both transactions will eventually succeed. If one of them fails for some reason, but the matching process happened anyway, then the data becomes inconsistent, so its not ideal.

The other idea which I have thought of is if I don't find the record, then sleep and try again, assuming that the other transaction will commit during this time. What do you think of that idea, I still need to figure out if it will solve the problem or not, but I am not generally fond of this type of idea.

Paul Sturrock wrote:
Not sure what "matching" denotes, but could you tolerate unmatched entries until the next transaction runs? i.e. transaction one and two run close together, leaving some data needing resolved. When transaction three comes along it picks this data up?


That is another idea which we have thought of, either to have a batch process that runs at some stage, and resolves all the unmatched ones, or at the beginning of each call, check if there were any unmatched ones from previous calls. What I don't like about this one, is introducing extra overhead on every call, to solve a problem that only happens less than 1% of the time.

Thanks very much for the suggestions.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!