wood burning stoves 2.0*
The moose likes EJB and other Java EE Technologies and the fly likes Weblogic/Oracle and conccurent commits among clients Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Weblogic/Oracle and conccurent commits among clients" Watch "Weblogic/Oracle and conccurent commits among clients" New topic
Author

Weblogic/Oracle and conccurent commits among clients

Stephen Conlon
Greenhorn

Joined: Aug 07, 2001
Posts: 1
We are running into major issues when more than one user attempts to do updates in the database to the same rows. Is there a way to make WebLogic queue these requests from the clients?
From the WebLogic documentation:
Special note for Oracle Databases
Keep in mind that Oracle uses optimistic concurrency. As a consequence, even with a setting of TRANSACTION_SERIALIZABLE, Oracle does not detect serialization problems until commit time. The message returned is:

java.sql.SQLException: ORA-08177: can't serialize access for this transaction
Even if you use the TRANSACTION_SERIALIZABLE setting for an EJB, you may receive exceptions or rollbacks in the EJB client if contention occurs between clients for the same rows. To avoid these problems, you must ensure that clients catch and examine the SQL exceptions, and take appropriate action, such as restarting the transaction.
>> end WebLogic documentation
If this is all true, why exactly would we purchase such an expensive hunk of **** if we have to manage the transactions ourselves?
Anyone else running into this?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16142
    
  21

Nothing I've ever read in the EJB spec ever indicated to me that EJBs were expected to resolve high-level contention issues. There are too many ways of doing so to force just one on the system designer.
I think what they are getting at has to do with concurrent access from users outside the EJB system -- that is, when users update from both WebLogic and, say, a console client SQL request. Read that way, I'd take it as simply meaning that when a row is fetched as an EJB, there's no lock that can be acquired within Oracle to tell WebLogic not to reject the EJB changes out of hand -- instead you get a failure when the bean is saved to persistent storage. It's possible that among the concurrent clients where this might occur would be multiple WLS servers in a cluster.
You might seek clarification on the WebLogic-specific newsgroups (BEA's own, in particular) and/or those pertaining to Oracle.


Customer surveys are for companies who didn't pay proper attention to begin with.
subramaniam vaidyanathan
Greenhorn

Joined: Jun 25, 2001
Posts: 10
I'm too green a horn to be able to comment why its not available.. But I did have a similar problem in an application I worked on.. We had to resolve it ourselves.. We did it by having a Timestamp column in the table.. Every read from the table reads the timestamp too for that row.. Every update on that row updates the timestamp to current server time.. Now if a second user updates the row after a first user has read it and then when the first user tries to update the row, the timestamp that he read and that which is on the row now do not match and we do not update.. a simple where conTimeStamp = etc.. etc.. as part of the update statement..
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Weblogic/Oracle and conccurent commits among clients