jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: Confirming assumptions about transactional environment and session-handling
Date Thu, 10 Sep 2009 11:50:34 GMT
On Thu, Sep 10, 2009 at 09:29, Gamba <holger.breuer@handelshof.de> wrote:
> I'm running jackrabbit 1.6.0 on jboss 4.2.3 with mysql at the backend. All
> the code to access the jackrabbit-api is placed in a stateless session bean,
> in different methods (add node, delete node, ...). I'm using container
> managed transaction with tx_required on each method. Each method are using
> an own
> session with a technical user (the same in all methods) to read/write access
> jackrabbit. The session logout() method is called in a finally { .. } blocj
> at the end of each method.
> I have own node-types for nodes and files.
>
> 1) First of all I want to know if this is a common scenario or are there any
> known problems regarding
> the environment?

Typically it's good to have one session per request. This keeps things
simple: there is one login per user and the whole request
automatically one transaction (even if you don't use java tx) if you
have a single sesison.save() at the end of the request. Apache Sling
for example works that way and does authentication handling and
session login for you and simply passes that to servlets. But of
course there are cases where you want more fine control or you need to
handle it more specific if you have parts that will belong to a
distributed transaction.

> After implementing this I'm reading something about locks and concurrent
> updates and asks myself
> If I need the mixin-typ mix:lockable for my own nodes. After reading the
> Spec 8.4.10 I think I don't need
> the mixin types and did not handle manually node-locking, because I'm
> working in a transactional environment:
>
> "As a result, if a lock is enabled and then disabled within the same
> transaction, its effect never makes it to the persistent workspace and
> therefore it does nothing. In order to use locks properly (that is, to
> prevent the “lost update problem”), locking and unlocking must be done in
> separate
> transactions."
>
> 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.

> 3) So I did not expect an InvalidItemStateExcpeton?

Sorry, I don't understand what you mean by this question?

> 4) Have I call the session.save() method inside my method-transactions. Or
> is it saved automatically
> on a the transaction-commit?

You have to call it yourself, it's not done automatically. That would
be crazy. The only important thing to note is that when transactions
are enabled, a session save won't persist the data as it is the case
w/o transactions. This will be postponed to the (successful) commit of
the transaction.

> 5) Are there any known session-complications with only one technical user in
> this environment?

What do you mean by "only one technical user"?

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Mime
View raw message