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
