Hi,
Thanks, someone finally looked at the code more.
Yes, Jaws can't set the transaction isolation, the DataSource is just a
facade for getting a Connection(handle) to a XA/ManagedConnection that
actually talks to the db and has the transaction associated with it by the
XAResource. By the time Jaws gets the connection , the transaction has
already been associated. (the xa wrappers do this by finding the connection
that the transactin was actually started on, and using it). So, I think
the transaction-associating code ought to be able to set transaction
isolation too, at the same time. There are 2 cases I think will work:
1. xa wrappers, a jdbc 1 connection can only have one transaction at a
time, no suspend/resume. So you set the isolation when you create the
transaction initially, and ignore it thereafter ( you should always be
setting it to the same isolation anyway).
2. This will also work for the jca firebird driver I am working on for
essentially the same reason.
However I don't know what would happen with someone elses true xa driver.
Since you can only have one transaction associated with an xa resource at a
time, I would expect it to be possible to set the isolation before
associating the transaction... but I don't know that there is an interface
for doing this.
Basically the problem is that the isolation is a property of the
transaction, but java doesn't put it there.
I'm rapidly starting to think that this may be too much trouble.
Bill, I think you were the main motivation for all this dynamic isolation
configuring. Can you eliminate your need for serializable transactions on
a few tables by explicitly keeping several versions around and finding a
way to get the correct version?
david jencks
On 2001.06.27 14:32:01 -0400 Bill Burke wrote:
>
<big snip>
> > 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
