>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
