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