> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Wednesday, June 27, 2001 1:20 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] CVS update:
> jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
>
>
> |> Sorry, I rolled back the code before you responded. If you want
> |me to put
> |> it back in, I will it takes about 10 minutes. I think I made a
> |> mistake and
> |> made the first change to quick (it was easy) , and I think we
> |> need to figure
> |> out what we are doing (design before code).
>
> ok let's pause a second
>
> |Again, I'll reiterate, I strongly suggest NOT defining transaction
> |isolation
> |levels in JAWS nor at at any other level other than in the
> definition of a
> |connection pool or other data resource. You'd really have to
> redesign and
> |rewrite how JAWS interacts with data resources and frankly, I think the
> |abstraction that is already there provides the most flexibility(it uses
> |javax.sql.DataSource) in plugging in DataSources other than the stuff in
> |jbosspool. In fact, the EJB 2.0 spec supports some of the things
> |I'm trying
> |to say here. "Isolation Levels 17.3.2"
>
> in fact I think it supports the "generic pools"
>
> |"The following are guidelines for managing isolation levels in enterprise
> |beans.
> |
> |- The API for managing an isolation level is resource-manager specific.
> |(Therefore, the EJB architecture does not define an API for managing
> |isolation level.)
>
> I am glad to see that the isolation levels were removed, they are indeed
> JDBC specific. But JAWS is jdbc specific, jaws accesses the resource
> manager jdbc directly.
>
BUT, JAWS has no concept on whether it is or not within a transaction. The
DataSource abstracts this.
> |- If an enterprise bean uses multiple resource managers, the
> Bean Provider
> |may specify the same or different isolation level for each
> |resource manager.
> |This means, for example, that if an enterprise bean accesses multiple
> |resource managers in a transaction, access to each resource
> manager may be
> |associated with a different isolation level.
>
> precisely, so the isolation level is specific to a BEAN and not to a
> resource manager. This makes total sense, the beans know the
> record they are
> working on and what they do and can tell the driver "read-only pal". In
> your scenario we put that knowledge at the pool level configuration and we
> deploy a pool PER COLLECTION OF LOCKED RECORDS we are going to access PER
> APPLICATION. You are saying that for each bean deployed we will create a
> new pool and set the isolation level on all the connections to the given
> isolation level. The isolation level is metadata of the pool in your case
> and you have a pool per different type of bean deployed. In my
> mind this is
> application/db-record metadata.
>
> |- The Bean Provider must take care when setting an isolation level. Most
> |resource managers require that all accesses to the resource
> |manager within a
> |transaction are done with the same isolation level. An attempt to change
>
> that is fine we don't change within the transaction.
>
> |the isolation level in the middle of a transaction may cause undesirable
> |behaviour, such as an implicit sync point."
> |
> |Theres more interesting stuff, but I don't feel like typing it in.
> |
> |Bill
>
I hope I'm not wasting your time here, but I think I have some valid points.
> Bill are you saying..
>
> BeanA BeanB
> / \ / \
> PoolA PoolB PoolC PoolD <--- configure here
> \ \ / /
> \ \ / /
> \ /
> \ /
> DB1
>
Nope, I'm saying this
ReadCommittedPool
SerializedPool
(BTW, Oracle only supports READ_COMMITTED and SERIALIZED)
BeanA BeanB
\ /
ReadCommitted SerializedPool
\ /
\ /
\ /
DB1
BeanA/jaws.xml
# You want BeanA to access DB with isolation level READ_COMMITTED
<datasource>ReadCommittedPool</datasource>
BeanB/jaws.xml
# You want BeanA to access DB with isolation level SERIALIZED
<datasource>SerializedPool</datasource>
> I am saying
>
> BeanA BeanB <---- configure here
> \ /
> PoolA
> |
> DB1
>
> So we have one pool and you get your connection and you set the isolation
> level corresponding to your bean description do your work, the db knows to
> read that isolation level and you put the connection back when
> you are done
> and start over...
>
This would be ideal, but.....read on....
JAWS does the following:
(pseudo code, look in JDBCCommand.java for more detail)
jdbcExecute(...)
{
DataSource ds = jawsEntity.getDataSource();
Connection con = ds.getConnection();
PreparedStatement stmt = con.createPreparedStatement(...)
yadayadayada
}
I'm pretty sure that the jbosspool
stuff(org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl) will give back the
same Connection with every "ds.getConnection()" while within the same
transaction. Thus, with the current code base, you cannot do
connection.setIsolationLevel at the JAWS level.
This may be different with the JCA stuff though. Can somebody elaborate?
> btw the guys who does the work from BeanA->PoolA is jaws and he has the
> context on how to set the isolation levels, i.e. the metadata from the
> *application*
>
> since PoolA drivers support setting the isolation level outside
> transactions
> this would work.
>
> Am I correct in saying that the pool will not hand out a
> connection that is
> associated with a transaction? If so you only get connections that are
> clear and clean...
>
Again, I'm pretty sure you're wrong here. The pools will hand out the same
connection that is already associated with the transaction you are in. Do
you get my point now? You're going to have to change the abstraction
between JAWS and the "data source".
I don't know, maybe it is as easy as
jdbcExecute(...)
{
JBossDataSource ds = (JBossDataSource)jawsEntity.getDataSource();
Connection con = ds.getConnectionWithIsolation(SERIALIZED);
PreparedStatement stmt = con.createPreparedStatement(...)
yadayadayada
}
But this change is practically the same as having 2 separately defined
pools.
> right? I mean I don't know :) I could be wrong (really)
>
> so why the many pools
> ?
>
I will double check on this, but David Jencks has a real good point. Unless
we're using real XA and 2pc, mixing isolation levels between beans to the
same DB is real risky. And isn't the buzz that, at least for Oracle, the XA
drivers are real buggy?
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
