|"setTransactionIsolation:
|
|Note: This method cannot be called while in the middle of a transaction."
you win...
marcf
PS: and it is a shame :) the isolation is isolation of the state that is
touched (the records), so in my ideal world i would use a transaction to
update the databases, one connection per database, and say "this record and
that record rw, you ro etc etc" but that is my ideal web transaction world
and it is worlds apart from the database transaction world. Oh well, back
to locking
|
|Bill
|
|
|
|> -----Original Message-----
|> From: [EMAIL PROTECTED]
|> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
|> fleury
|> Sent: Wednesday, June 27, 2001 3:59 PM
|> To: [EMAIL PROTECTED]
|> Subject: RE: [JBoss-dev] CVS update:
|> jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
|>
|>
|> |> 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
|>
|
|
|
|_______________________________________________
|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
