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