Hi,
sorry to nitpick, however my experience with Oracle's implementation of
read committed is that all operations done in a transaction are definitely
visible within that transaction. They are not visible to other
transactions until you commit. This is the standard industry wide meaning
of read committed. Can you imagine using a database where you couldn't
verify the effects of your work until after you had committed them?????
david jencks
On 2001.06.15 13:14:50 -0400 Gina Hagg wrote:
> Sorry, I have been out for a while.
> Just wanted to say that
> Read committed is the default and was the only
> automatic isolation level provided before Oracle
> Release 7.3.
> And Read committed is still the default which doesn't
> let anybody even within the transaction see the
> updated changes.
>
> However, you are right, they added Serializable after
> 7.3 which you have to set up as the isolation level,
> which allows you within a transaction see the changes
> you have made.
> And it is only in this mode that you can.
> Of course, SQLPlus is Oracle specific which by the way
> uses SQLNet and not some JDBC-ODBC driver, and has
> serializable settings.
>
> Oracle does advise Read Committed as isolation setting
> , therefore i have rarely seen companies use anything
> but that...
> Sorry, if i caused confusion..
>
> --- David Jencks <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Hey guys, think a minute. What transaction
> > isolation means is _other_
> > transactions can't see your work until you commit.
> > Of course _your_
> > transaction can see everything you've done. If
> > you're working with say the
> > oracle interactive interface and insert a record in
> > a table, if you query
> > the table you can see it right away, you don't have
> > to commit first.
> > _other_ people can't see it until you commit. This
> > has nothing to do with
> > xa or anything else.
> >
> > [although there is a related issue with "tightly
> > coupled" and "loosely
> > coupled" transaction branches in xa: loosely coupled
> > means different
> > branches of the same transaction can't see each
> > others work. This should
> > only arise when several transaction managers are
> > using the same global
> > transaction against the same resource, and the
> > XAResources can't agree that
> > they are using the same resource. Maybe this is
> > what you guys are thinking
> > of, but this should only be a potential problem with
> > distributed jboss]
> >
> > I'm pretty sure someone else complained about this a
> > couple of weeks ago,
> > although I can't find the reference - they were
> > modifying an entity, then
> > doing a finder method returning a collection
> > including the "just modified"
> > bean, except they weren't seeing the modifications.
> >
> > In my opinion, if this requirement was not present
> > in ejb 1.1, is was a
> > serious requirements bug, encouraging logically
> > inconsistent behaviour from
> > the container.
> >
> > Thanks, Bill.
> >
> > david jencks
<snip>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
