I just spent the last several hours reading everything I could possibly
find about this topic, and I would like to retract my former explanation
and issue a new one :-)
Here's my current best guess as to how all this stuff works. I hope
someone will correct any misconceptions.
1) Dirty reads don't happen in EJBland because for any given
transaction, an entity will be loaded at most once. No matter what
happens to the database, an entity bean involved in a transaction will
work perfectly normally *at least* until commit time.
2) Finders might return different results in the same transaction, so
the phantom read is still possible.
3) Commit Option C means that the state of an entity bean is ejbLoaded
at the start of *every* transaction. Commit Option A means that entity
bean state remains vaild between transactions (the bean is cached), so
an ejbLoad is unnecessary for new transactions. Orion allows us to
toggle which commit option is used with the "exclusive-write-access"
attribute in orion-ejb-jar.xml.
4) Optimistic concurrency allows multiple transactions to simultaneously
access a single entity. This is done by creating multiple entity bean
instances, each of which load their state at the start of the
transaction (ala Commit Option C). The bean instances can be modified
independently. When each of the transactions are committed, the
entity's old state is checked against the actual state in the database
and if they differ, the transaction is aborted. This results in an
exception that the client must handle (probably by redoing the
transaction). Thus this concurrency model is "optimistic" because it
expects that collisions will rarely occur.
5) Pessimistic concurrency means the app server serializes transactions
which access an entity, guaranteeing that exceptions will never be
thrown to the client because of the collision problem found in the
optimistic model. Commit Option A is used, providing the performance
advantage of eliminating the need for frequent ejbLoads, but the
performance disadvantage of serialized transactions.
6) Pessimistic concurrency and Commit Option A start to seriously break
down in a clustered environment because of the difficulty and
performance cost of maintaining a single bean instance (or replicating
its state).
These are pure, wild speculation:
7) Orion uses pessimistic concurrency if exclusive-write-access is true,
optimistic concurrency if exclusive-write-access is false. ?
8) If you cluster Orion, it uses optimistic concurrency. ?
9) If exclusive-write-access is false, and you externally modify the
value of an entity in the database during a transaction which also
modifies that value, Orion will throw an exception when you try to
commit the transaction. ?
I'm certain that at least in the simple case, Orion is using Commit
Option A (and pessimistic concurrency) because a) I have observed that
selects (ejbLoads) are not issued repeatedly to the JDBC driver and b)
the decompiled counter.jar has no code for handling special error
conditions.
For general enlightenment purposes, this thread is especially good
reading material:
http://www.mail-archive.com/ejb-interest@java.sun.com/msg13276.html
The slides for this conference session have a pretty fair discussion of
isolation levels:
http://jsp.java.sun.com/javaone/javaone2000/event.jsp?eventId=678
Jeff
>-----Original Message-----
>From: Dan Winfield [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, January 31, 2001 12:36 AM
>To: Orion-Interest
>Subject: Re: Session EJB Accessibility
>
>
>I am sure a dirty read is when an object has an old set of values when
>compared to the database. This does happen in optimistic concurrency
>control.
>
>Dan
>----- Original Message -----
>From: "Vidur Dhanda" <[EMAIL PROTECTED]>
>To: "Orion-Interest" <[EMAIL PROTECTED]>
>Sent: Wednesday, January 31, 2001 7:52 AM
>Subject: Re: Session EJB Accessibility
>
>
>> I believe Orion uses pessimistic concurrency control.
>However, I don't
>> think optimistic concurrency control would allow dirty reads -- I
>understand
>> a dirty read to imply a transaction seeing the uncommitted state of
>another
>> transaction.
>>
>> Vidur
>>
>> Jeff Schnitzer wrote:
>>
>> > >From: Gary Shea [mailto:[EMAIL PROTECTED]]
>> > >
>> > >I could use a little help here. My limited understanding
>of entity
>> > >beans suggests that if I create an EB using a particular
>> > >key value, as long as I refer only to that same key value there
>> > >would only be one instance of the EB. Is that not true because
>> > >of optimizations that allow bean pooling of a particular EB for
>> > >a particular value of that EB's primary key if
>'optimistic concurrency'
>> > >is assumed? What _is_ 'optimistic concurrency' anyway, he said,
>> > >exposing the full depth of his ignorance...
>> >
>> > This article is good explanation:
>> > http://theserverside.com/resources/news1.jsp#dev
>> >
>> > The details are spelled out in sections 9.6.9 and 9.6.10
>of the EJB2.0
>> > spec, but it's pretty esoteric.
>> >
>> > Basically: With pessimistic concurrency, the app server
>ensures that
>> > only a record is only represented by a single entity bean
>and serializes
>> > transactions on that bean. With optimistic concurrency,
>the app server
>> > allows a bean instance to be created for each transaction.
> This is much
>> > faster (no waiting for the other transaction to commit)
>but allows the
>> > possibility of dirty reads.
>> >
>> > It's analagous to isolation levels in the database.
>> >
>> > I'm not quite sure what Orion does, and I wish someone
>would chime in
>> > with a comment or two in this respect. I'm about to decompile the
>> > counter.jar example in hope of finding some clues.
>> >
>> > Jeff
>>
>> --
>> Vidur Dhanda
>> Active Solutions
>> tel: 617/566-1252
>> [EMAIL PROTECTED]
>> www.active-solutions-inc.com
>>
>>
>>
>
>
>
