jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pablo Rios" <pr...@bea.com>
Subject RE: concurrent writes (JCR-314)
Date Sat, 23 Jun 2007 04:34:06 GMT
Regarding the steps below required to support concurrent writes, what considerations should
be taken into account in connection with JCR-18 issue ? How does the Shared ISM instance for
the global VersionManager works ?
 
Thanks,
Pablo

________________________________

From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
Sent: Mon 6/4/2007 1:56 AM
To: users@jackrabbit.apache.org
Subject: Re: concurrent writes (JCR-314)



Hi Rafal, 

Rafal Kwiecien 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 


Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.

Mime
View raw message