I would use the terms pessimistic *locking* vs. optimistic *locking*.
These are the usual terms used, not pessimistic concurrency vs.
optimistic concurrency. These are not just database terms. They are also
related to long vs. short transactions. For the duration of a transaction,
a row in the database can be locked (depending on isolation level). This
is why the long transaction model is not scalable and why we need to perform
our own checks at the application level (using timestamps for example)
if we use the short transaction model. The long model is like a pessimistic
lock
in that you lock the row when you read the data and keep it until you're
ready
to write the data back. Part four (122) pages of the Gray and Reuter book on
Transaction Processing is entirely dedicated to this issue, but I couldn't
find
a simple definition....
I found one definition in "Principles of Transaction Processing" by
Bernstein and
Newcomer for Optimistic concurrency control [they do speak of concurrency in
their
chapter about locking, no wonder we're confused]:
"The idea of executing an operation without setting locks, and checking that
the operation is still valid at commit time, is called optimistic
concurrency
control. It is considered optimistic because you have to be optimistic that
the
check at commit time is usually OK. If it fails, the penalty is rather
high - you
have to abort the whole transaction."
>From this definition, the opposite, pessimistic concurrency control, would
consist
of setting a lock at the beginning of the transaction and knowing for sure
that the
commit will succeed. See the link with long transaction vs. short ones? In
the long
transaction model you hold on to all the resources necessary to ensure
succesfull
commit. In the short model you have to verify.
As far as the weblogic issue, I'm not sure on that either. I heard a friend
of mine, who's a database architect, complain about this issue too, but I
forgot
the details. I'll ask him next time I see him. Perhaps they do a
"select for update" when they read the data for the bean, which would mean
they
lock the row for the entire cycle from ejbLoad to ejbStore, instead of
starting
separate DB transactions for each. However, I can't believe this is true....
Even in a cluster, is there ever only one instance of an EB for the same
pk???
That would not be particularly scalable as a single EB can only handle so
many
requests...
Whoops, this tuned out to be a lot longer than I expected. Hope it's
relevant.
Cheers,
Frank Sauer
The Technical Resource Connection
Tampa, FL
http://www.trcinc.com
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Floyd Marinescu
> Sent: Wednesday, September 20, 2000 2:54 AM
> To: [EMAIL PROTECTED]
> Subject: how about a definitive defintion of optimistic and
> pessimistic
> concurrency
>
>
> Hi everyone,
>
> I am preparing a short article on advanced entity
> bean topics and I would
> like to confirm some confusing definitions with you.
>
> Pessimistic and Optimistic Concurrency
> Algorithms used by a database to handle concurrent access to
> data. With
> pessimistic concurrency, only one transaction can use a row
> in the db at a
> time (depending on isolation level). With optimistic, there
> is no locking
> going on, but transactional collisions/diamonds are detected
> and appropriate
> transactions are rolled bac.
>
> One entity bean per PK in memory vs. multiple
> This is simply a design decision used by application servers on how to
> handle entity beans. App. servers like weblogic have only one
> entity bean
> per PK in memory, thus all access to the entity bean is
> serialized. Other
> app. servers allow multiple instances per pk to be in memory,
> and rely on
> the database to do isolation control.
>
>
> The confusing part here is why people on this list insist on calling
> Weblogic's one-entity-per-pk strategy "pessimistic
> concurrency", and other
> app. server's multiple-entity's-per-pk strategy "Optimistic
> Concurrency". I
> thought that the terminology pessimistic/optimistic apply
> only to database
> issues. How exactly can these terms be used when describing
> app. servers?
>
> thanks everyone,
>
> Floyd
>
> ---------------------------------
> Senior Architect / Director of Marketing
> The Middleware Company
> http://www.middleware-company.com
> http://www.TheServerSide.com
> [EMAIL PROTECTED]
> 416-889-6115
>
> Check out TheServerSide.com, the internets first J2EE community!!!
>
> ==============================================================
> =============
> 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".
