marc fleury wrote:
> |But if they're in the same transaction, they must use the same isolation
> |level - per our discussion on the database doing an implicite commit
> |when you try to change levels. I don't think it makes logical sense to
> |talk about having two different transaction isolation levels in the same
> |transaction, either - either the transaction is serializable or the
> |transaction is read-committed.
>
> why not?????????????
>
> the STATE is read-committed or not, meaning that a "theoretical" level I
> have no problem saying that a transaction can encompass beans that are
> read-only (most of them, like a calendar and a whachamakalit list of stuff
> (menu) from where you select your products taht doesn't change (catalog?))
> but the "order" would of course be read write. For design reasons I might
> want to use the global transaction to emcompass the records and have
> different isolations on their state.
>
> You don't agree?
>
> marcf
I'm thinking of the isolation level as an immutable part of the
transaction - partly because this is how the databases implement it (at
least as far as JDBC goes).
Sure, it would be useful to be able to specify different levels per
bean, but given the apparent constraints that the databases are putting
us under, implementing it against the database isn't feasable.
Now, if we do move the notion of isolation level into the container
further (which I think we've both mentioned) so that we can get the
cache's et. al. helping us out, then I can certainly agree with your
'theoretical' case.
-danch
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
