this is an educating discussion, I never had before to think precisely of
all the objects involved..
however
|I think you are agreeing with what I proposed earlier, if you have say a
|session bean method with Requires/Serialiable calling 17 entity bean
|methods with Requires/Read Committed, the entire transaction (started when
|you get to the session bean) will be Serializable. If only one resource
I am not following
|manager is available, only it will be used.(one pool) This means different
|methods on one bean can have different transaction isolations.
what it means to me is that a transaction can be updating records with
different isolation levels with the SAME connection to the database.
I AM WRONG ON THIS ASSUMPTION? (that is ALL my discussion)
If no then 2 pools (2 types of connection IL) and 1 transaction uses 2
connections, XA required
if yes then 1 pool (2 types of connection IL) and 1 transaction uses 1
connection, no XA required
|Bill wants each entity bean to have an immutable transaction isolation for
yes and my question is "why immutable", it is the yes and no above.
|all its methods, and to be able to have several transaction isolations
|within one transaction, using several pools connected to the same db. As I
|have pointed out previously, this doesn't work the the wrapped jbosspool
|fake xa. You get 2 indenpendent concurrent transactions, but there is no
|guarantee that they will both succeed or fail. To get real transactions,
|you need read xa drivers and probably to use real 2pc. ( it is conceivable
|that a sophisticated driver could recognize that both resources are the
|same, and use 1pc. THIS DOES NOT MEAN THE FAKE XA WRAPPERS WILL DO THIS).
yes that is a problem with his multi-pool design, that you do require XA
synchronization for using different ILs with the db (WHICH WOULD SEEM VERY
NORMAL TO ME). On the other hand 1 connection does not require XA and 2PC,
not that they are bad, just that they are much slower. XA is for many
connections, we are talking about requiring many connections because of a
claim that we cannot reset ILs within one connection.
I want to make sure that the multipool design is a *requirement*, a "no
other way" as he seems to indicate. The contention point in my mind is the
simple question above
can we set different ILs on a jdbc connection within one transaction
respect,
marcf
|
|david jencks
|
|
|>
|> 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
