Hi Nicolas,
Nicolas Belisle wrote:
> no, but you may use locks to further control isolation level.
There seems to be at least two problems with that approach :
- You will get a (unpleasant) javax.jcr.lock.LockException if another
transaction tries to lock the node (or a child).
You probably want a lock call that is blocking and returns when the lock
could be retrieved. Locks in jsr-170 were primarily designed to lock
nodes for a longer time and not just while in a transaction. Maybe a
blocking variant of the getLock() method is something we should consider
for the next jcr version.
- It is not enforced even though it should be used everywhere, even for
only a read.
This depends on the application. I don't think you have to lock the
workspace when your applicaton is fine with an read-committed isolation
level.
Sorry there was an error in my example. I should make more sense this way :
Example v.2 :
A : open session
A : read nodes "test" & "test2"
B : open session
B : delete nodes "test" & "test2"
B : save session //WHAT SHOULD HAPPEN ??
B : logout
A : read nodes "test" & "test2" //WHAT SHOULD HAPPEN ??
A : logout
yeah, that definitively makes more sense ;)
deleting the two nodes with Session B will be successful, unless session
A has locked the two nodes.
regarding the second attempt to read the two nodes with session A, this
depends whether A already obtained references to the nodes or not.
If A already has reference to those two nodes, calles that read the
state of those nodes will throw an InvalidItemStateException. Indicating
that the nodes do not exist anymore.
If A tries to retrieve the nodes again. E.g. by calling getNodes() on
the parent of the just deleted nodes. The returned NodeIterator will
simply not contain the nodes anymore.
It would be useful if the isolation level could configured at the
repository level. So if your application needs better isolation or
performance you would only need to change the configuration and not your
code.
Again I think this always depends on the application on top of the
repository. Setting an isolation level as a global property does not
seems to be a good idea to me.
An implementation could (hypothetically) use locks in SessionImpl and
use events (when a session saves/logout) to prevent throwing exceptions.
A queue would hold pending operations. However, we would have to be
careful about long lived sessions...
I'm sorry, I cannot follow you here...
regards
marcel
