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
>
>
>
