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

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

right? I mean I don't know :) I could be wrong (really)

so why the many pools
?

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

Reply via email to