[jira] Commented: (JCR-204) Improve recoverability
[ https://issues.apache.org/jira/browse/JCR-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473642 ] Marcel Reutegger commented on JCR-204: -- No, the index is always updated after the persistence manager successfully committed the transaction. It may happen though that a query selects a node that still exists in the persistence manager but is deleted in your session or un-committed transaction. > Improve recoverability > -- > > Key: JCR-204 > URL: https://issues.apache.org/jira/browse/JCR-204 > Project: Jackrabbit > Issue Type: Improvement > Components: core, indexing, observation, transactions > Environment: svn revision: 265028 >Reporter: Marcel Reutegger > Assigned To: Marcel Reutegger >Priority: Minor > > Transactions in Jackrabbit are committed in SharedItemStateManager.store(). > While the call to PersistenceManager.store() is by its definition atomic, > updates on the index through synchronous notification by the > ObservationManager are not. Consequently, it may happen that the index is not > up-to-date with the workspace data in case of a crash. > Consider the following cases: > 1) > - changes in a ChangeLog are successfully stored by the persistence manager > - the observation manager notifies the query handler about the change > - the query handler starts to update the index > - system crashes > -> the index is missing some changes > 2) > - changes in a ChangeLog are successfully stored by the persistence manager > - system crashes > -> the index is missing all changes > To prevent situations like 1) the index must be fully transactional > implementing ACID properties. > In case an index update cannot be completed, the index will appear as if the > update never happened. Which results in a situation described in example 2) > To prevent situations like 2) the observation manager musts keep track of > transactions and make sure that committed transactions (the ones that > successfully stored the changes in the persistence manager) successfully > notify all listeners. If the system should crash while listeners are notified > the events must be re-delivered on restart. > comments and suggestions on alternatives are welcome! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-745) TCK: more tests assuming that 'addMixin' immediately taking effect
TCK: more tests assuming that 'addMixin' immediately taking effect -- Key: JCR-745 URL: https://issues.apache.org/jira/browse/JCR-745 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: angela Priority: Minor Attachments: TCK_rev_502263.patch jsr170 allows an implementation to have Node.addMixin only taking affect upon a save-call. some tests already got adjusted. attached patch for additional tests, that make usage of addMixin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-745) TCK: more tests assuming that 'addMixin' immediately taking effect
[ https://issues.apache.org/jira/browse/JCR-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-745: --- Attachment: TCK_rev_502263.patch > TCK: more tests assuming that 'addMixin' immediately taking effect > -- > > Key: JCR-745 > URL: https://issues.apache.org/jira/browse/JCR-745 > Project: Jackrabbit > Issue Type: Bug > Components: JCR TCK >Reporter: angela >Priority: Minor > Attachments: TCK_rev_502263.patch > > > jsr170 allows an implementation to have Node.addMixin only taking affect upon > a save-call. > some tests already got adjusted. > attached patch for additional tests, that make usage of addMixin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-746) TCK: check for wrong repository descriptor. should be versioning instead of locking
TCK: check for wrong repository descriptor. should be versioning instead of locking --- Key: JCR-746 URL: https://issues.apache.org/jira/browse/JCR-746 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: angela Priority: Minor Attachments: TCK_rev_502263_wrong_descritor.patch ... at least according to the comment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-746) TCK: check for wrong repository descriptor. should be versioning instead of locking
[ https://issues.apache.org/jira/browse/JCR-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-746: --- Attachment: TCK_rev_502263_wrong_descritor.patch > TCK: check for wrong repository descriptor. should be versioning instead of > locking > --- > > Key: JCR-746 > URL: https://issues.apache.org/jira/browse/JCR-746 > Project: Jackrabbit > Issue Type: Bug > Components: JCR TCK >Reporter: angela >Priority: Minor > Attachments: TCK_rev_502263_wrong_descritor.patch > > > ... at least according to the comment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-721) Duplicate key in DatabasePersistenceManager
[
https://issues.apache.org/jira/browse/JCR-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned JCR-721:
-
Assignee: Stefan Guggisberg
> Duplicate key in DatabasePersistenceManager
> ---
>
> Key: JCR-721
> URL: https://issues.apache.org/jira/browse/JCR-721
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.1
> Environment: JackRabbit 1.2.1 using the default Derby repository.xml.
>Reporter: Martijn Hendriks
> Assigned To: Stefan Guggisberg
> Attachments: Jcr721Test.java
>
>
> Hi,
> I ran into the exception pasted below. We had 2 threads that both were
> saving. Maybe it is a race condition?
> Regards,
> Martijn Hendriks
> creative online development B.V.
>
> t: 024 - 3888 261
> f: 024 - 3888 621
> e: [EMAIL PROTECTED]
>
> Wijchenseweg 111
> 6538 SW Nijmegen
> http://www.gx.nl/
> Jan 26, 2007 2:23:36 PM
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager store
> SEVERE: failed to write property state:
> e3847bad-f1ee-4adb-a109-e134900935b7/{http://gx.nl}edit_language
> ERROR 23505: The statement was aborted because it would have caused a
> duplicate key value in a unique or primary key constraint or unique in dex
> identified by 'DEFAULT_PROP_IDX' defined on 'DEFAULT_PROP'.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.IndexChanger.insert(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown
> Source)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.executeStmt(DatabasePersistenceManager.java:835)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:466)
> at
> org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:274)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:675)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:808)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:302)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:295)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1210)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-747) TCK: observation tests are too restrictive
TCK: observation tests are too restrictive -- Key: JCR-747 URL: https://issues.apache.org/jira/browse/JCR-747 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Affects Versions: 1.0 Reporter: Marcel Reutegger Priority: Minor The basic sequence in all observation tests is: 1) add listener 2) modify workspace 3) remove listener 4) wait for events on listener This sequence forces an implementation to maintain a logical order for listener registrations and content changes. In the light of the asynchronous nature of observation events this seems too restrictive for certain implementations. The sequence should be changed to: 1) add listener 2) modify workspace 3) wait for events on listener 4) remove listener Which is also more intuitive from a user perspective. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-747) TCK: observation tests are too restrictive
[ https://issues.apache.org/jira/browse/JCR-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-747. -- Resolution: Fixed Fixed in svn revision: 508421 > TCK: observation tests are too restrictive > -- > > Key: JCR-747 > URL: https://issues.apache.org/jira/browse/JCR-747 > Project: Jackrabbit > Issue Type: Bug > Components: JCR TCK >Affects Versions: 1.0 >Reporter: Marcel Reutegger >Priority: Minor > > The basic sequence in all observation tests is: > 1) add listener > 2) modify workspace > 3) remove listener > 4) wait for events on listener > This sequence forces an implementation to maintain a logical order for > listener registrations and content changes. In the light of the asynchronous > nature of observation events this seems too restrictive for certain > implementations. > The sequence should be changed to: > 1) add listener > 2) modify workspace > 3) wait for events on listener > 4) remove listener > Which is also more intuitive from a user perspective. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-721) Duplicate key in DatabasePersistenceManager
[
https://issues.apache.org/jira/browse/JCR-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated JCR-721:
--
Fix Version/s: 1.2.2
> Duplicate key in DatabasePersistenceManager
> ---
>
> Key: JCR-721
> URL: https://issues.apache.org/jira/browse/JCR-721
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.1
> Environment: JackRabbit 1.2.1 using the default Derby repository.xml.
>Reporter: Martijn Hendriks
> Assigned To: Stefan Guggisberg
> Fix For: 1.2.2
>
> Attachments: Jcr721Test.java
>
>
> Hi,
> I ran into the exception pasted below. We had 2 threads that both were
> saving. Maybe it is a race condition?
> Regards,
> Martijn Hendriks
> creative online development B.V.
>
> t: 024 - 3888 261
> f: 024 - 3888 621
> e: [EMAIL PROTECTED]
>
> Wijchenseweg 111
> 6538 SW Nijmegen
> http://www.gx.nl/
> Jan 26, 2007 2:23:36 PM
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager store
> SEVERE: failed to write property state:
> e3847bad-f1ee-4adb-a109-e134900935b7/{http://gx.nl}edit_language
> ERROR 23505: The statement was aborted because it would have caused a
> duplicate key value in a unique or primary key constraint or unique in dex
> identified by 'DEFAULT_PROP_IDX' defined on 'DEFAULT_PROP'.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.IndexChanger.insert(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown
> Source)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.executeStmt(DatabasePersistenceManager.java:835)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:466)
> at
> org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:274)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:675)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:808)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:302)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:295)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1210)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-721) Duplicate key in DatabasePersistenceManager
[
https://issues.apache.org/jira/browse/JCR-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved JCR-721.
---
Resolution: Fixed
martijn, thanks for the excellent and spot-on issue ananlysis, great job!
i fixed the issue, i.e. endless loop in
DatabasePersistenceManager.store(ChangeLog), as suggested in svn r508429.
i agree that it would be nice if a more descriptive exception would be thrown
(e.g. StaleItemStateException). unfortunately this would require a seperate
select stmt for every property insert and therefore negatively affect
performance. i don't think it's worth it.
> Duplicate key in DatabasePersistenceManager
> ---
>
> Key: JCR-721
> URL: https://issues.apache.org/jira/browse/JCR-721
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.1
> Environment: JackRabbit 1.2.1 using the default Derby repository.xml.
>Reporter: Martijn Hendriks
> Assigned To: Stefan Guggisberg
> Attachments: Jcr721Test.java
>
>
> Hi,
> I ran into the exception pasted below. We had 2 threads that both were
> saving. Maybe it is a race condition?
> Regards,
> Martijn Hendriks
> creative online development B.V.
>
> t: 024 - 3888 261
> f: 024 - 3888 621
> e: [EMAIL PROTECTED]
>
> Wijchenseweg 111
> 6538 SW Nijmegen
> http://www.gx.nl/
> Jan 26, 2007 2:23:36 PM
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager store
> SEVERE: failed to write property state:
> e3847bad-f1ee-4adb-a109-e134900935b7/{http://gx.nl}edit_language
> ERROR 23505: The statement was aborted because it would have caused a
> duplicate key value in a unique or primary key constraint or unique in dex
> identified by 'DEFAULT_PROP_IDX' defined on 'DEFAULT_PROP'.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.IndexChanger.insert(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown
> Source)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.executeStmt(DatabasePersistenceManager.java:835)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:466)
> at
> org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:274)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:675)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:808)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:302)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:295)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1210)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[VOTE] Release Apache Jackrabbit 1.2.2
Hi, I have posted a candidate for the Apache Jackrabbit 1.2.2 release at http://people.apache.org/~jukka/jackrabbit/1.2.2/ See the included RELEASE-NOTES.txt file for details on release contents and latest changes. The release was made from the 1.2 branch after merging all the bug fixes listed in the release notes. Note that even though this is a patch release, I've included two clustering changes that are not strictly bug fixes on the grounds that the clustering feature is still in beta level. Please vote on releasing these packages as Apache Jackrabbit 1.2.2. The vote is open for the next 72 hours, and only votes from Jackrabbit committers are binding. The vote passes if at least three +1 votes are cast. [ ] +1 Release the packages as Apache Jackrabbit 1.2.2 [ ] -1 Do not release the packages because... BR, Jukka Zitting
Re: [VOTE] Release Apache Jackrabbit 1.2.2
Hi, On 2/16/07, Jukka Zitting <[EMAIL PROTECTED]> wrote: Please vote on releasing these packages as Apache Jackrabbit 1.2.2. [x] +1 Release the packages as Apache Jackrabbit 1.2.2 [ ] -1 Do not release the packages because... BR, Jukka Zitting
[jira] Resolved: (JCR-746) TCK: check for wrong repository descriptor. should be versioning instead of locking
[ https://issues.apache.org/jira/browse/JCR-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-746. -- Resolution: Fixed I agree, it should be a check for the version option. Fixed in revision: 508486 Thank you for the patch. > TCK: check for wrong repository descriptor. should be versioning instead of > locking > --- > > Key: JCR-746 > URL: https://issues.apache.org/jira/browse/JCR-746 > Project: Jackrabbit > Issue Type: Bug > Components: JCR TCK >Reporter: angela >Priority: Minor > Attachments: TCK_rev_502263_wrong_descritor.patch > > > ... at least according to the comment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-745) TCK: more tests assuming that 'addMixin' immediately taking effect
[ https://issues.apache.org/jira/browse/JCR-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-745. -- Resolution: Fixed Committed changes as proposed in revision: 508492 Thank you for the patch. > TCK: more tests assuming that 'addMixin' immediately taking effect > -- > > Key: JCR-745 > URL: https://issues.apache.org/jira/browse/JCR-745 > Project: Jackrabbit > Issue Type: Bug > Components: JCR TCK >Reporter: angela >Priority: Minor > Attachments: TCK_rev_502263.patch > > > jsr170 allows an implementation to have Node.addMixin only taking affect upon > a save-call. > some tests already got adjusted. > attached patch for additional tests, that make usage of addMixin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Compiling with eclipse/maven2
Hi,I'm having problems with Maven2. It says that the javax.jcr dependency is missing. I have tried everything including downloading the jar and pointing maven's dependency's local dir to it. Everything else is standard out of the box, no changes. Does anyone use eclipse/subclipse/maven to work on jackrabbit?Which other IDEs do people prefer?Thanks. _ Life is complicated. Sharing yours shouldn’t be. Meet Muse. http://muse.live.com?source=wlmailtag&loc=us
