|> Bill are you saying..
|>
|>   BeanA       BeanB
|>    / \         /  \
|> PoolA PoolB  PoolC PoolD  <--- configure here
|>   \     \     /     /
|>     \     \ /     /
|>        \       /
|>           \ /
|>           DB1
|>
|
|Nope, I'm saying this
|
|
|ReadCommittedPool
|SerializedPool

so just 2 pools per database existing, one per isolation level

no duplication per bean?

mmm at least its simpler than I thought... but again are we sure that we
CANNOT change the isolation levels within one transaction?

if (we can NOT change) 2 pools
if (we can change) 1 pool

|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>

sure it is simple, do you need 2 pools though?

|> 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.


which is what I meant, that the pool will not hand out a connection already
in a transaction to another transaction.  SO when you get a connection it is
already and only associated to your transaction only.  Setting your
isolation level should be transparent to the driver it is a discussion you
are having with the database (but I understand you are saying that setting
different isolation levels WITHIN a transaction results in commit?).


|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.

no no no I am saying

jdbcExecute(..)
{
ds=getDataSource();
ds.setIL(whatever);
do work;
}

well you are stuck with this "I have to use the right pool from the get go"
and my questions are more around the setting of isolation levels within a
transaction.  Regardless of the pool.

since we all know that you get the same connection all the time that is
good.

|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

hmmmm that's orthogonal (if I read that paragraph right), my thinking here
(but I could be wrong on how the drivers do it) is that your driver only
knows the transaction and registers with it to listen to the demarcation.
It is the db that manages the isolation of the queries on individual records
and it does so based on tags that you passed to it through the connection.
That you set the isolation level at the beginning, statically, or that you
set them within the transaction (ONE transaction) should not make a
difference and certainly should NOT commit the transaction going on.  But
you seem to indicate that a connection in a given transaction cannot modify
its isolation level to talk to different records it is static.

Transaction A {

  uses connection 1
      setIL(readserialized)
        talks to "customer" records and that is readserialized,
      setIL(readcommited) <-- Driver will commit transaction A????
      talks to "debitcard" records and that is readcommited,
  }
}

the connection is a connection period, and you tell it wich IL to use for
the next invocations. Obviously different ILs on the same record would throw
exceptions but same IL on same records, even if you have many ILs because
many records, within the same transaction.

I guess I tend to think of the isolation as a record thing, not a
transaction thing, even though we use the transaction to implement it

marcf



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

Reply via email to