Hi, Maybe 'non transactional' is the wrong expression. Such persistence managers (for example the ObjectPersistenceManager) usually work OK, you can use transactions in Jackrabbit and so on, the exception is 'atomicy' in a crash. When the process is stopped while a transaction is persisted (power failure, process killed, Runtime.halt() called, VM crash), some data of a transaction may be committed and some not. Theoretically, some nodes may even be corrupt (depending how and when the system crashed). But the algorithms used are minimizing this risk, for example the parent node is written last so in 99% of the cases there is no problem even after a crash.
As far as I know, the database persistence managers (bundle and simple) are safe, all others are not fully. Of course it depends on how safe a database is (if you have a power failure, even databases get corrupted sometimes, depending on the file system / hard drive). I will update the wiki. Thomas On 9/20/07, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > On 9/20/07, KÖLL Claus <[EMAIL PROTECTED]> wrote: > > so my opinion is it should be regardless which peristence manager you use > > jackrabbit should be always transactional if a operation runs inside a > > transaction > > context. is this true or not ? > > You need to have a persistence manager that can store the transaction > changelog as a single atomic operation, which as of now means the > database persistence managers. An underlying database transaction is > still needed for that atomic change, but it's not a part of the > externally managed transaction context. > > BR, > > Jukka Zitting >
