[
https://issues.apache.org/jira/browse/JCR-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626408#comment-13626408
]
Shashank Gupta commented on JCR-3547:
-------------------------------------
>I wonder why they didn't fail before when running concurrently, if they
>actually accessed the same repository concurrently? Or don't they access the
>same repository?
afaiu, they don't access same repository. AbstractJCRTest#setup do initialize
new repository for each test case.
> But then they should still be able to run concurrently, right?
They were failing because of Approach 1. (due to static flag) . with approach
2, they successfully ran concurrently.
> Because it's quite a big change, I think somebody else should have a look as
> well, specially the changes in the RepositoryContext and RepositoryImpl
Should I go for RTC?
> Datastore GC doesn't reset updateModifiedDateOnAccess on datastore
> ------------------------------------------------------------------
>
> Key: JCR-3547
> URL: https://issues.apache.org/jira/browse/JCR-3547
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.4, 2.5
> Reporter: Shashank Gupta
> Attachments: GarbageCollector.java.patch,
> GC_prevent_concurrent_run_app2.patch, GC_prevent_concurrnet_run_app1.patch
>
>
> In mark phase, GC updates store.updateModifiedDateOnAccess with current time,
> so that datastore updates record’s lastModified timestamp upon subsequent
> read/scan.
> But GC doesn't reset it to 0. So even after GC completes, datastore will
> continue updating lastModified timestamp on read invocations and it will have
> performance impact.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
