Hi,
On 2001.06.27 13:20:21 -0400 marc fleury wrote:
> |> 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.
On the other hand jca has ConnectionRequestInfo, which might well include
transaction isolation if the resource adapter supports more than one level.
>
> |- 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
>
> Bill are you saying..
>
> BeanA BeanB
> / \ / \
> PoolA PoolB PoolC PoolD <--- configure here
> \ \ / /
> \ \ / /
> \ /
> \ /
> DB1
>
> 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....
>
> 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...
Well, connections are just handles, managed connections are what actually
talks to the db, but whatever they are, what's in the pool is not
associated with a transaction: the container associates the
connection/handle with the correct transaction on the way to handing it
out. So the container can set the transaction isolation right then before
the transaction association.
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
manager is available, only it will be used.(one pool) This means different
methods on one bean can have different transaction isolations.
>
> right? I mean I don't know :) I could be wrong (really)
>
> so why the many pools
> ?
Bill wants each entity bean to have an immutable transaction isolation for
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).
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
