jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Zeigermann" <oli...@zeigermann.de>
Subject Re: concurrent writes (JCR-314)
Date Mon, 04 Jun 2007 14:04:48 GMT
I am not deeply into the problem, but why is there locking on the Java
side anyway? It really should be possible to get along with DB locks
only.

Calling the DB from synchronized blocks always bears the danger of deadlocks.

Oliver

2007/6/4, Miguel Ángel Jiménez <miguel.js@gmail.com>:
> 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
> >
>
>
>
> --
> Miguel.
>
Mime
View raw message