> > > > |Please correct me if I'm wrong(I seem to be wrong about 50% of the
> > > > |time :-),
> > > > |but, I really don't think you should expose transaction-isolation
> > levels
> > > > |within CMP or in the definition of entities.  This really belongs
in
> > the
> > > > |creation of the connection pool.  CMP cannot really guarantee that
a
> > > > |connection will not be shared between different entity types
> > > > |within the same
> > > > |transaction that use the same connection pool.  Actually, I'm
pretty
> > sure
> > > >
> > > > which is why I am asking if the jdbc drivers support
> > reconfiguration of
> > > the
> > > > isolation level on the fly or is it pretty much a
> > "constructor" thingy.
> > > >
> > > > btw if it is the good case (we can change it) then it is not up to
> > minerva
> > > > to do this, all minerva does is hand out the connection but
> > it is up to
> > a
> > > > functional unit above it, one aware of the application accessing
this
> > > > connection.  That would live in JCA, but it would need to know the
> > > > applciation context, or it would purely live in the app server
sphere
> > > (i.e.
> > > > jaws getting the connection, or asking the container to do it on its
> > > behalf,
> > > > whatever we can do that call somewhere, factored or not).
> > > >
> > > > am i making sense?
> > > >
> > >
> > > I think I understand now.  Here is some text I found the  J2EE
tutorial:
> > >
> > > ------------
> > > You cannot modify the isolation level of a entity beans with
> > > container-managed persistence. These beans use the default
> > isolation level
> > > of the DBMS, which is usually READ_COMMITTED.  For entity beans with
> > > bean-managed persistence and for all session beans, you can set the
> > > isolation level programmatically with the API provided by the
underlying
> > > DBMS. A DBMS, for example, might allow you to permit
> > uncommitted reads by
> > > invoking the setTransactionIsolation method:
> > >
> > > Connection con;
> > > ...
> > > con.setTransactionIsolation(TRANSACTION_READ_UNCOMMITTED);
> > >
> > > Do not change the isolation level in the middle of a
> > transaction. Usually,
> > > such a change causes the DBMS software to issue an implicit commit.
> > Because
> > > the isolation levels offered by DBMS vendors may vary, you should
check
> > the
> > > DBMS documentation for more information.
> > > -----------
> > >
> > > So the code I added probably causes an "implicit commit,"  which is
bad.
> > > From my very JDBC centric perspective, this should be set in Minerva
> > > (JBossPool?) and user configurable. I don't know much about the
> > connector
> > > architecture, so maybe Minerva is the wrong place.
> > >
> > > Any way, I think I should roll back my change. If you agree
> > marc, just say
> > > so and it is done.
> > >
> > > I don't know any thing about Minerva, so if you want that
> > changed, someone
> > > else would be better suited.  If no one wants to do it, I'll look at
it.
> > >
> > > -dain
> > >
> >
>
> I know what to do for Minerva(aka org.jboss.pool.jdbc, correct?) and can
put
> these changes in.  But I really wouldn't know what to do with JCA, that
is,
> if a change is required there as well.
>
> Bill
>

I agree.  IMHO we should move this to minerva and roll back my code.  With
the implicit comit junk, I don't think there is any other option.  If JCA
person is watching this thread, please pipe up and what you would like to
see.

Any way I will roll it back in an hour or so.

-dain

BTW. Section 17.3.2 of the EJB 2.0 spec says, "For session beans and
message-driven beans with bean-managed transaction demarcation, the Bean
Provider can specify the desirable isolation level programmatically in the
enterprise bean's methods, using the resource-manager specific API. For
example, the Bean Provider can use the
java.sql.Connection.setTransactionIsolation(...) method to set the
appropriate isolation level for database access."  I don't know if a BMT
gets a 'virgin' connection from minerva, but if it doesn't we could get
implict commits.


_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to