Alexander Klimetschek wrote:
> 
>> 2) Is it correct that I need not bother with such locking issues?
> 
>> Only if you want to set locks. Otherwise you just have to be aware
>> that an exception might occur because a node has been locked by
>> another session (if that can be the case). With transactions, I think
>> you will get this exception on commit.
> 

Hm. I thought, in a transactional environment the locks are released on
a session commit when I use session-scoped locks and I thought that's the
only
useful thing in that case.

So I wonder if I need any locking in my environment?



Alexander Klimetschek wrote:
> 
>> 3) So I did not expect an InvalidItemStateExcpeton?
> Sorry, I don't understand what you mean by this question?
> 

And that the reason I thought there will not be such exceptions,
because all changes are persisted at commit-time. Hm ... ok,
when another session updates the same node, then the exception
could occur ... Is it possible to use refresh() in that case, before
saving the session?




Alexander Klimetschek wrote:
> 
>> 5) Are there any known session-complications with only one technical user
>> in
>> this environment?
> What do you mean by "only one technical user"?
> 

At the moment, we have only one and same user for all session-logins calling
...
repository.login(new SimpleCredentials("technical", "passwd".toCharArray()),
"default");

We ware in test-state at the moment and not in production with our
application.
But in production I think we need also only one user, because our
authentication-access 
is done in a speparate component. So are there any problems which can occur
with only one user
to acces jackrabbit with multiple thread calling staless-sb-methods and each
method 
getting the session with the shown statement?

Thx
Gamba




-- 
View this message in context: http://www.nabble.com/Confirming-assumptions-about-transactional-environment-and-session-handling-tp25378625p25382645.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.