ah, interesting subject. Heres another (database-centric) view:
- dirty read (also referred to as "uncommitted read") means that one
transaction can see changes another transaction has performed, but not yet
committed.
- optimistic concurrency means that a transaction, upon changing data, does
not acquire an exclusive lock on the same. Instead, the lock is aquired at
commit time, when also a check for conflicting changes is performed (based
on data values or timestamps). The changes do not become visible to
concurrent transactions before commit time.
in that sense, dirty read and optimistic concurrency preclude eachother. In
any case, "dirty read" refers to reading, OC to writing.
----- Original Message -----
From: "Dan Winfield" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Wednesday, January 31, 2001 9:36 AM
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
> >
> >
> >
>
>
