jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller" <thomas.tom.muel...@gmail.com>
Subject Re: System slowdown
Date Thu, 20 Sep 2007 09:41:12 GMT

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.


On 9/20/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> On 9/20/07, KÖLL Claus <C.KOELL@tirol.gv.at> 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

View raw message