fine-grained transactions

[subsstuff]

I hope this is the correct forum for transaction queries.

I understand that to set isolation levels, you modify the descriptor specific to your database.
I also know that JBoss cant do function-level isolation.

Does this mean that the isolation level I set in the xml descriptor (for DB2 in my case) will dictate an isolation strategy for ALL beans in my system?

Also, will DB2's isolation settings take precedent over that which I define to JBoss?


Cheers,
Kenny

[subsstuff]

Hi all, i simply want to select names start with something,

I wrote;
* @jboss:finder-query name="findName1"
* query="name1 LIKE {1} "
* order = "name1"
* @ejb:finder signature="java.util.Collection
findName1( java.lang.String name)"
* result-type-mapping="Local"

but i can't understand what is wrong with that.

[davidjencks]

Transaction isolation is set per datasource. You might be able to use 2 datasources for 2 different isolation levels, but you'd need bmp or 2 sets of ejbs.

I don't know what you mean by "DB2's isolation settings" If you set a tx isolation level in your jboss datasource config, every connection from that datasource will have its isolation level set to the one you specified before it is handed out to you.

There is apparently a way to mark a resource unsharable so you can safely change the tx isolation settings in your code, but you will probably need bmt.

I have not yet seen a plausible explanation of why a reasonably designed system would want different tx isolation levels.

[subsstuff]

> Transaction isolation is set per datasource. You
> might be able to use 2 datasources for 2 different
> isolation levels, but you'd need bmp or 2 sets of
> ejbs.
Ouch, not a good idea.

> I don't know what you mean by "DB2's isolation
> settings" If you set a tx isolation level in your
It allows me to set a default isolation level. I think that it would override the one specified by me in the JBoss descriptors, but have to test to find out.

> There is apparently a way to mark a resource
> unsharable so you can safely change the tx isolation
> settings in your code, but you will probably need
> bmt.
Again: ouch.

> I have not yet seen a plausible explanation of why a
> reasonably designed system would want different tx
> isolation levels.
I am no expert and may be talking junk, but it seems to me that this is a feature many people would want.
It seems plausible that you would require different locking strategies depending on the context you are involved in.
For instance; I have a very large number of clients connecting to a server for data. I would like to dish it out via some very low overhead locking mode: accuracy of the data is not critical, but the response time is.

On the other hand, in the same system, I have numerous updates to perform on data in the same database. When I do this (and there are lots of such commits), I want to use the highest level (SYNCHRONIZED), since this is premium data and has to be correct at all times.

I dont know if this can be done in JBoss, since I can only specify one level. Also, in some other containers (I think Weblogic for eg) you can set different isolation modes at a method-level?
Since I cant do this, I would then have to use SYNCHRONIZED for the entire system - rather be safe than sorry.

thanks,
Kenny

[davidjencks]

I don't think tx isolation is a plausible way to work with the situation you describe.

If you are using only one jboss server, use commit option a and there will be no db access for reads of an already loaded entity.

If you are using multiple (clustered) jboss servers, there has been some discussion that commit option b and read access outside a tx would be desirable. This is not currently supported by jboss.

With normal locking in jboss, jboss serializes the calls to a single entity anyway, so even read committed isolation will give you consistent results. With the multi- locking scheme you should use the select for update feature to lock beans for consistency.

Another option is to use a database that provides low overhead consistent views of the data, such as firebird.

One really big problem with trying to specify tx isolation per method is that it is usually not possible to change the isolation within a tx, so this imposes limits on which methods can be included in a tx, essentially breaking the declarative tx boundary feature of ejbs.