Kenny, Pessimistic concurrency can be handled by the database. But it can also be handled by the AppServer. I believe a few vendors implemented things this way (WebLogic (pre 6.x) works this way) but others (like us :) create as many instances of entity beans as there are simultaneous transactions. These run in parallel and it is up to the Container to manage the synchronization between these different instances. Obviously the latter is way faster [and scalable] compared to the former.
See my response to Suresh Babu's post for more details. In brief, databases can handle pessimistic concurrency, but this works differently for different vendors (as mentioned in my first response). -krish > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Kenny Macleod > Sent: Thursday, December 20, 2001 12:42 PM > To: [EMAIL PROTECTED] > Subject: Re: Concurrent access of entity object > > > Isn't pessimistic concurrency always handled by the database? > > > > -----Original Message----- > > From: SureshBabu Sreeramulu [mailto:[EMAIL PROTECTED]] > > Sent: 20 December 2001 11:39 > > To: [EMAIL PROTECTED] > > Subject: Re: Concurrent access of entity object > > > > > > How an Application Server can handle the pessimistic concurrency > > implementation in a Clustered environment? > > > > -----Original Message----- > > From: Krishnan Subramanian [SMTP:[EMAIL PROTECTED]] > > Sent: Thursday, December 20, 2001 4:14 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Concurrnet access of entity object > > > > Saminathan, > > > > Actually, the answer depends on the vendor's EJB Container > > implementation. > > > > Some vendors typically serialize access to a single entity > > bean instance in an attempt to solve the problem arising out > > of concurrent client access to an entity bean. However, this > > solution is not scalable and is conceptually flawed when the > > EJB Container itself is clustered. > > > > Again, some EJB vendors attempt to push concurrency out of > > the AppServer and into the database. However, this might not > > work with all databases (such as Oracle). > > > > For the above, the solution is to use Serialization isolation > > level for your entity beans. This implies lower concurrency > > and also a higher load on your database. In addition to this, > > some DB vendors have a different syntax. Oracle for > > example uses > > the "SELECT ... FOR UPDATE" syntax while for other vendors > > such as M$ SQL Server, simply setting the isolation level > > for the JDBC driver datasource will work (this will not work > > for Oracle though for which you have to use the > > syntax mentioned > > above). > > > > The other solution is to push concurrency out of the database > > and into the AppServer. This way, you can get away with using > > a lower isolation level. In effect, you are pulling the load > > out of the database and into the AppServer. Since databases > > can be scaled only vertically (a bigger box/more cpus in the > > same box), you may be killing performance (when using a higher > > isolation level) by saturating your database. With concurrency > > being handled by the AppServer, you can use the concept of > > verified updates. That is, verify at the time of updating the > > database that the values of the persisted fields you read in > > (at the start of the transaction) are indeed the values that > > are currently in the database: > > > > (UPDATE <SomeTable> SET <NewValues> WHERE <[All/Updated]_CMP_ > > > > Field_Values_Are_The_Ones_Read_In_At_Start_Of_The_Transaction>) > > > > The above syntax is supported by our AppServer as well. > > And since AppServers can be scaled horizontally, you can > > scale up performance by running the AppServer on more boxes. > > Consequently, if a given EJB application puts a lighter load > > on your database, the same database can be used for more > > applications. > > > > -krish > > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans development > > [mailto:[EMAIL PROTECTED]]On Behalf Of SAMINATHAN > > Sent: Monday, December 20, 1999 6:30 AM > > To: [EMAIL PROTECTED] > > Subject: Concurrnet access of entity object > > > > > > hi > > > > we are developing a standard alone application with > > EJB in the > > middle tier and Swing in the front end.And we are using > > completely BMP entity for accessing our data. > > > > The case is like this > > > > I have client A and client B > > > > my client A calls my ejbLoad() and gets all the > > record 1 in the > > form and started modifying and in the mean time > > my client B also calls the ejbLoad() for the record 1 > > and started > > modifying the record. > > > > I don't have any issues when the first client or in > > that matter who > > ever updates first . > > > > but when the second client tries to update after the > > first one , > > what will happen to my data integrity? > > > > and what about ACID properties ? > > > > > > Can some one kindly let me know whether these kind of > > issues will be > > taken care by container or not? > > > > Thanks in advance > > > > Saminathan. > > > > > > ============================================================== > > ============= > > To unsubscribe, send email to [EMAIL PROTECTED] > > and include in > > the body > > of the message "signoff EJB-INTEREST". For general > > help, send email > > to > > [EMAIL PROTECTED] and include in the body of the > > message "help". > > ************************************************************** > > ************ > > This email (including any attachments) is intended for the > > sole use of the > > intended recipient/s and may contain material that is CONFIDENTIAL AND > > PRIVATE COMPANY INFORMATION. Any review or reliance by others > > or copying or > > distribution or forwarding of any or all of the contents in > > this message is > > STRICTLY PROHIBITED. If you are not the intended recipient, > > please contact > > the sender by email and delete all copies; your cooperation > > in this regard > > is appreciated. > > ************************************************************** > > ************ > > > > ============================================================== > > ============= > > To unsubscribe, send email to [EMAIL PROTECTED] and > > include in the body > > of the message "signoff EJB-INTEREST". For general help, > > send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
