jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Miguel Ángel Jiménez" <miguel...@gmail.com>
Subject Re: concurrent writes (JCR-314)
Date Mon, 04 Jun 2007 10:08:59 GMT
I did some tests removing synchronized blocks from
BundleDbPersistenceManager and AbstractBundlePersistenceManager and all went
fine, but I think thorough testing is needed in this field.

I would also like to see jackrabbit doing concurrent writes at its core,
delegating the lock management to the PersistenceManager implementation. A
BundleDbPersistenceManager could possibly offer concurrent writes whereas a
file based persistence manager might do one write at a time.

Best regards,

On 04/06/07, Marcel Reutegger <marcel.reutegger@gmx.net> wrote:
> Hi Rafał,
> Rafał Kwiecień wrote:
> > Ok.So, how long it can take? 2 or 3 months? half year ?
> > It is important to me to know when this feature will be available.
> jackrabbit is an open source project and does not have a fixed road map
> nor
> detailed release plan. if such a feature is important to you, you are very
> welcome to participate.
> afaics the following steps are required to be able to support concurrent
> writes:
> - implement a ISMLocking that supports multiple write locks at a time
> - extend an existing or create a new persistence manager to support
> concurrent
> writes
> - make sure the jackrabbit core is able to handle concurrent writes. e.g.
> check
> if caches are synchronized properly.
> - optionally: enhance the search handler implementation to support
> concurrent
> writes. (this is not a hard requirement because when jackrabbit indexes
> content
> the write lock had been downgraded to a read lock)
> > I use BundlePersistenceManager. Methods in that persistence manager are
> > synchronized. So, there is not possible to read anything during write.
> can you please file a jira issue about this and if possible attach a
> patch? thanks.
> > BTW. If I use FineGrainedISMLocking, sometimes I see a warning in logs:
> > WARN  [.core.query.lucene.SearchIndex] Exception while creating document
> for
> > node: aad7aa6a-5baf-4a33-b88d-f39f713aad1a:
> javax.jcr.RepositoryException:
> > Missing child node entry for node with id:
> > aad7aa6a-5baf-4a33-b88d-f39f713aad1a
> > Does it mean that some node has not been indexed ?
> > When I use DefaultISMLocking, I don't get warnings.
> please note that FineGrainedISMLocking is work in progress. there are some
> implications when using this class that need to be resolved first before
> it can
> be used. e.g. access to caches are not properly synchronized when using
> FineGrainedISMLocking.
> regards
>   marcel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message