jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister" <dominique.pfis...@day.com>
Subject Re: DatabaseJournal doesn't work with springmodules
Date Wed, 28 Mar 2007 13:52:21 GMT
Hi Rafał,

a test case will probably not be necessary. Looks like the
DatabaseJournal does not save the returned revision_id along with the
record currently being created but rather as one of its instance
member variables and therefore incorrectly associates both records
with the same revision_id. The commit() call after having inserted
only the first of two records is another defect: apparently the
DatabaseJournal's lock is not truly reentrant. I will file a jira
issue for this.

Thanks for reporting this bug!
Dominique

On 3/28/07, Rafał Kwiecień <rafal@consol.pl> wrote:
> Hi Dominique
>
> Dnia środa, 28 marca 2007 09:46, Dominique Pfister napisał:
> > Hi Rafał,
> >
> > judging from the fact that the revision id is incremented twice and
> > then applied to two different records, I ask myself whether these
> > records are appended from the *same* thread in the *same* instance.
> Yes - the same thread and the same instance of DatabaseJournal
>
> > When appending a record to the DatabaseJournal, the order of SQL calls
> > is as follows:
> >
> > -- BEGIN TRANSACTION --
> > UPDATE global_revision SET revision_id = revision_id + 1
> > SELECT revision_id FROM global_revision
> > INSERT INTO revision(revision_id, ...) VALUES (?,...)
> > -- COMMIT --
>
> I my case it looks like:
>
> -- BEGIN TRANSACTION --
> UPDATE global_revision SET revision_id = revision_id + 1
> SELECT revision_id FROM global_revision
> UPDATE global_revision SET revision_id = revision_id + 1
> SELECT revision_id FROM global_revision
> INSERT INTO revision(revision_id, ...) VALUES (?,...)
> -- COMMIT --
> INSERT INTO revision(revision_id, ...) VALUES (?,...)
> -- COMMIT --
>
> >
> > The first call is supposed to lock the global_revision table, the
> > second will fetch the new revision_id and the last one will append a
> > record with that new revision_id. If two instances would get the same
> > revision_id, something would be seriously strange with the database
> > transaction isolation. Two different threads in the same instance
> > block each other until one has actually finished appending the new
> > record. Therefore, the only conceivable scenario are  reentrant
> > updates made by the same thread.
>
> After debugging I can say more about the problem. When transaction is
> committed, there are methods prepare() and commit() called on
> TransactionContext object. TransactionContext.resources contains five
> objects: XAWorkspace, XAItemStateManager, XALockManager, XAVersionManager,
> XAWorkspace. First TransactionContext.prepare() is called - and for each
> resource prepare(). DatabaseJournal.doLock() is called twice (by
> XAItemStateManager and XAVersionManager). When TransactionContext.commit() is
> called, also method commit() for each resource is called. And
> DatabaseJournal.append() is called twice (also by XAItemStateManager and
> XAVersionManager).
>
> >
> > Can you reproduce your situation with a simple test case? This would
> > definitely help...
>
> Sorry, I don't have simple test case. You can download spring-modules package
> and run jcr sample. If you add cluster configuration to jackrabbit-repo.xml,
> you get error.
>
>
> --
> Rafał Kwiecień
> ConSol* Consulting & Solutions Software Poland Sp. z o.o.
> ul. Piastowska 44C, 30-070 Kraków
> http://www.consol.pl/
>
Mime
View raw message