jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu ☀" <the.mindstorm.mailingl...@gmail.com>
Subject Re: concurrent writes (JCR-314)
Date Mon, 04 Jun 2007 15:05:19 GMT
On 6/4/07, Oliver Zeigermann <oliver@zeigermann.de> wrote:
> 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.
>

Basically because the implementation of JCR is not required to work on
top of a RDBMS. Moreover, the persistence managers have been usually
created to be used over different persistence solutions (and over
different RDBMS, which have different locking support/mechanisms).

./alex
--
.w( the_mindstorm )p.

> 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