|I disagree....well, at least for our app, we have transactions where some
|entities really need to be serialized and other entities within the
|transaction are just fine with read_committed.

we will need to express this in code, but there are really 2 levels of
synchronization that need to happen. One is the db, one is the container
cache*s*..

the db will isolate the transaction very well, and provide read bla bla at
the "connection" level, whether the drivers support it and whether it is the
same consequences on all dbs is to be seen but that is a way.

We can also do "read only" beans in cache that would REALLY speed things up
(no need to always reload no need to go to the DB AT ALL, except the first
time we get in cache) and that is very configurable, as low as we want.

2 different things, same result isolation, one is superior in throughput and
management,

marcf
|
|Bill
|
|> -----Original Message-----
|> From: [EMAIL PROTECTED]
|> [mailto:[EMAIL PROTECTED]]On Behalf Of David
|> Jencks
|> Sent: Tuesday, June 26, 2001 4:43 PM
|> To: [EMAIL PROTECTED]
|> Subject: Re: [JBoss-dev] High load...
|>
|>
|> Hi,
|>
|> Forgive me if I am talking nonsense, but doesn't it only make
|> sense to have
|> transaction isolation per transaction????  I very much doubt you
|will find
|> a db that can support several transaction isolation levels within one
|> transaction.  I can't quite figure out what it would mean, either.  So I
|> say, put it with the transaction requirements for methods - Requires,
|> Requires New, etc.  Then you can set the isolation each time you start a
|> new transaction, based on this specification.
|>
|> david jencks
|>
|> On 2001.06.26 14:48:00 -0400 Dain Sundstrom wrote:
|> > > |I added transaction isolation to the new cmp plugin. You can
|> set it by
|> > > |adding the  <transaction-isolation> element after the datasource
|> > element.
|> > > |Valid levels are:
|> > > |    transaction-none
|> > > |    transaction-read-committed
|> > > |    transaction-read-uncommitted
|> > > |    transaction-repeatable-read
|> > > |    transaction-serializable
|> > > |
|> > > |Give me 10 minutes and I'll add it to JAWS...
|> > >
|> > > ok but these will be leveraged by new caches in JBoss 3.0
|> > >
|> > >
|> > >
|> > > so I would imagine that each application can set its own datasource
|> > > isolation level, (different kinds of bean).  So it IS user
|> configurable
|> > > right???
|> > >
|> > > Also how does it play with the datasources, if the datasource
|> is shared
|> > > across applications and different tables support different locking
|> > policies
|> > > (say one table is RO the other RW) can the driver support sequential
|> > > "setIsolationLevel" that only applies to the record and or table
|> > touched?
|> > > marcf
|> > >
|> >
|> > Right now this the jaws and jbosscmp code only support datasource per
|> > application.  When we implement datasource per bean, we can have
|> > isolation
|> > level per bean.  This leads to the intresting situation with EJB-QL
|> > queries
|> > that thouch multiput beans. May be we need to specify an
|isolation lever
|> > for
|> > each query.  Havn't thought about it much.  Right now you can
|> only set it
|> > for the entire ejb-jar.
|> >
|> > Just tell me when you get the cache stuff figgured out and I can update
|> > jaws
|> > and jbosscmp to support what ever you want.
|> >
|> > -dain
|> >
|> >
|> > _______________________________________________
|> > 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

Reply via email to