On Thu, Sep 10, 2009 at 09:29, Gamba <[email protected]> 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 [email protected]
