Problem with write.lock file generated by Lucene

[Mickaël Gervais]

Hi,
I'm using spring-data-neo4j, and an embedded database.

I've an instance of embedded database, et an other one in read only
mode.

When I access the first one, I can see that a file write.lock is
generated, so if I access the second instance, it cannot create the
lock file.

Here is the exception stack trace:

Caused by: java.nio.channels.OverlappingFileLockException
at sun.nio.ch.FileChannelImpl
$SharedFileLockTable.checkList(FileChannelImpl.java:1166)
at sun.nio.ch.FileChannelImpl
$SharedFileLockTable.add(FileChannelImpl.java:1068)
at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:868)
at java.nio.channels.FileChannel.tryLock(FileChannel.java:962)
at
org.apache.lucene.store.NativeFSLock.obtain(NativeFSLockFactory.java:
216)
at org.apache.lucene.store.Lock.obtain(Lock.java:72)
at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1108)
at
org.neo4j.index.impl.lucene.LuceneDataSource.getIndexWriter(LuceneDataSource.java:
613)
at
org.neo4j.index.impl.lucene.LuceneDataSource.getIndexSearcher(LuceneDataSource.java:
508)
at org.neo4j.index.impl.lucene.LuceneIndex.query(LuceneIndex.java:
267)
at org.neo4j.index.impl.lucene.LuceneIndex.query(LuceneIndex.java:
226)
at
org.springframework.data.neo4j.repository.AbstractGraphRepository.getIndexHits(AbstractGraphRepository.java:
182)
at
org.springframework.data.neo4j.repository.AbstractGraphRepository.findByPropertyValue(AbstractGraphRepository.java:
170)
at
org.springframework.data.neo4j.repository.AbstractGraphRepository.findByPropertyValue(AbstractGraphRepository.java:
157)

Is this normal? Or is this a misuse?

Thanks

Mickael

[Noppanit]

I guess it's because you close the connection and try to open it again
once you want to use it?

[Michael Hunger]

What configuration do you use for your embedded and for the readonly graphdb?

Thanks

Michael

[Mickaël Gervais]

Thanks for your responses.
I'm using spring-data-neo4j 2.0.0.
Here is my configuration:

Project 1 (which use an embedded database
(org.neo4j.kernel.EmbeddedGraphDatabase)):
<neo4j:config storeDirectory="data/flink.db" />

Project 2: (which use the same database in readonly mode
(org.neo4j.kernel.EmbeddedReadOnlyGraphDatabase)):
<neo4j:config graphDatabaseService="gdbs" />
<bean id="gdbs" class="org.neo4j.kernel.EmbeddedReadOnlyGraphDatabase"
destroy-method="shutdown">
<constructor-arg name="storeDir" value="data/flink.db" />
</bean>

Thansk
Mickael

On Feb 20, 11:04 pm, Michael Hunger <michael.hun...@neotechnology.com>
wrote:

> > org.neo4j.index.impl.lucene.LuceneDataSource.getIndexWriter(LuceneDataSourc e.java:
> > 613)
> >    at
> > org.neo4j.index.impl.lucene.LuceneDataSource.getIndexSearcher(LuceneDataSou rce.java:

> > 508)
> >    at org.neo4j.index.impl.lucene.LuceneIndex.query(LuceneIndex.java:
> > 267)
> >    at org.neo4j.index.impl.lucene.LuceneIndex.query(LuceneIndex.java:
> > 226)
> >    at

> > org.springframework.data.neo4j.repository.AbstractGraphRepository.getIndexH its(AbstractGraphRepository.java:
> > 182)
> >    at
> > org.springframework.data.neo4j.repository.AbstractGraphRepository.findByPro pertyValue(AbstractGraphRepository.java:
> > 170)
> >    at
> > org.springframework.data.neo4j.repository.AbstractGraphRepository.findByPro pertyValue(AbstractGraphRepository.java:

[Mattias Persson]

That's unfortunately expected since neo4j gets an index reader from an index writer... even in the read-only graphdb case. Will have to fix that for this to work.

2012/2/21 Mickaël Gervais <mger...@agaetis.fr>

--
Mattias Persson, [mat...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com

[Mickaël Gervais]

Is there a work aroundd?
Thanks

On Feb 21, 10:19 am, Mattias Persson <matt...@neotechnology.com>
wrote:

> That's unfortunately expected since neo4j gets an index reader from an
> index writer... even in the read-only graphdb case. Will have to fix that
> for this to work.
>

> 2012/2/21 Mickaël Gervais <mgerv...@agaetis.fr>

> Mattias Persson, [matt...@neotechnology.com]
> Hacker, Neo Technologywww.neotechnology.com

[Mattias Persson]

I don't think so.

2012/2/21 Mickaël Gervais <mger...@agaetis.fr>