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".
