By pessimistic concurrency, I mean the serialized access to an EB instance.
EJB Container locks the source data for the entire time it needs the data,
not allowing anything else to potentially update the data until it completes
its transaction.
-----Original Message-----
From: Kenny Macleod [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, December 20, 2001 5:12 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".
**************************************************************************
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".
