David Fraser wrote: > Yura Smolsky wrote: >> Hello, Julien. >> >> JA> I'm currently using a RLock instead of the PythinFileLock. It works >> JA> perfectly well and the performance lose is really small compared with >> JA> the FSDirectory I was using (around 2%) I'm currently make long running >> JA> processes with bigger stores to see if the behavior remains correct. >> >> JA> In my case, I only have a Python thread pools so I guess the RLock will >> JA> work just great for NXLucene. >> >> cool! >> >> JA> There is something I'm wondering about the Java Lucene Lock >> JA> implementation though. Why do they actually need to use a file system >> JA> lock ? For being able to access the store from different JVMs ? >> >> Yes, so index can be used by many processes.. > This would be important, for example, in using PyLucene from within > multi-process, multi-thread Apache...
Hi David, I checked what was available nowadays in Java. NIO seems to rock ! http://www.onjava.com/pub/a/onjava/2002/10/02/javanio.html I found my answer there : """ File locks are primarily needed when integrating with non-Java applications, or between distinct JVMs. """ NIO offers a file lock abstraction as well: """ With NIO, file locks are built right into the FileChannel class. It's now easy to create, test, and manage file locks on any platform that supports file locks at the OS level. File locks are generally needed when integrating with non-Java applications, to mediate access to shared data files. """ Cheers, J. -- Julien Anguenot | Nuxeo R&D (Paris, France) Open Source ECM - www.nuxeo.com CPS Platform - http://www.cps-project.org Mobile: +33 (0) 6 72 57 57 66
signature.asc
Description: OpenPGP digital signature
_______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
