You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by anton_slutsky <as...@applevac.com> on 2006/11/07 19:35:31 UTC
Jackrabbit repo locking
Hello,
First of all, kudos on the great product. We are using it and love it
something awful. Having said that, one little "feature" that's there is
extremely annoying. When a repo is instantiated, it creates a .lock file
at root (which you probably know all too well). I'm sure there is a
reason for it to be there, and in prod it might even be a good idea to
make certain only one process access a given repository, but in
development, this .lock file causes a world of grief. I'm using
jackrabbit as a library for a web project running on jboss in dev and
websphere in prod. I constantly run into two major problems. First,
sometimes, I need to kill jboss, which negates any attempts at finalize()
logic I have implemented. Second, when redeploying, jboss seems to ignore
finalize() altogether when hot redeploying. Obviously, this is not your
issue, but it is a huge inconvenience for me and my team.
I'm wondering if I were to submit a patch making this .lock logic
configurable, how would it go with the team? Or are there underlying
architectural concerns that necessitate such an approach?
Thanks!
Anton
--
View this message in context: http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a7224255
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Jackrabbit repo locking
Posted by anton_slutsky <as...@applevac.com>.
In a pure VM runtime environment this is true. The lock is abandoned once
the VM dies. The problem I'm having occurs in a server environment. During
redeploy, it looks like the app server vm retains the nio lock even though
the application context should have been unloaded. This problem is probably
due to the fact that the garbage collector in a j2ee server is an
unpredictable entity and doesnt pick up the unloaded class instances for a
while after the undeploy occurs. Thus, all my attempts to "shutdown()" in
finalize() are wasted. I say "probably" because the above is something of
an educated guess -- I havent spent too much time figuring out the cause of
the issue -- but I think it's a good one.
anton_slutsky wrote:
>
> Hello,
>
> First of all, kudos on the great product. We are using it and love it
> something awful. Having said that, one little "feature" that's there is
> extremely annoying. When a repo is instantiated, it creates a .lock file
> at root (which you probably know all too well). I'm sure there is a
> reason for it to be there, and in prod it might even be a good idea to
> make certain only one process access a given repository, but in
> development, this .lock file causes a world of grief. I'm using
> jackrabbit as a library for a web project running on jboss in dev and
> websphere in prod. I constantly run into two major problems. First,
> sometimes, I need to kill jboss, which negates any attempts at finalize()
> logic I have implemented. Second, when redeploying, jboss seems to ignore
> finalize() altogether when hot redeploying. Obviously, this is not your
> issue, but it is a huge inconvenience for me and my team.
>
> I'm wondering if I were to submit a patch making this .lock logic
> configurable, how would it go with the team? Or are there underlying
> architectural concerns that necessitate such an approach?
>
> Thanks!
> Anton
>
--
View this message in context: http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a7794936
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Jackrabbit repo locking
Posted by Tobias Bocanegra <to...@day.com>.
hi anton,
we received many errors that were caused by multiple instances running
on the same repository data that's why the .lock file is there to
prevent 2 jackrabbit instances accessing the same physical data.
actually, it should not cause any trouble, even if the jvm is killed
or the repository is not shut down correctly.
the mechanism works as follows: if the .lock file is present, the
repository tries to acquire a java.nio.lock, and if this succeeds,
only a warning is issued. if not, another process has locked the file
and the repository startup is aborted. if the jvm is killed, it
releases also the lock of on the .lock file.
so i'm wondering what exact problems you see?
regards, toby
On 11/7/06, anton_slutsky <as...@applevac.com> wrote:
>
> Hello,
>
> First of all, kudos on the great product. We are using it and love it
> something awful. Having said that, one little "feature" that's there is
> extremely annoying. When a repo is instantiated, it creates a .lock file
> at root (which you probably know all too well). I'm sure there is a
> reason for it to be there, and in prod it might even be a good idea to
> make certain only one process access a given repository, but in
> development, this .lock file causes a world of grief. I'm using
> jackrabbit as a library for a web project running on jboss in dev and
> websphere in prod. I constantly run into two major problems. First,
> sometimes, I need to kill jboss, which negates any attempts at finalize()
> logic I have implemented. Second, when redeploying, jboss seems to ignore
> finalize() altogether when hot redeploying. Obviously, this is not your
> issue, but it is a huge inconvenience for me and my team.
>
> I'm wondering if I were to submit a patch making this .lock logic
> configurable, how would it go with the team? Or are there underlying
> architectural concerns that necessitate such an approach?
>
> Thanks!
> Anton
> --
> View this message in context: http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a7224255
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: Jackrabbit repo locking
Posted by anton_slutsky <as...@applevac.com>.
Thanks a bunch Thomas, I'll give it a shot. On the repository creation
issue, the JCR spec actually specifically says that they dont want to
specify how a Repository should be created. Looking at the Jackrabbit code,
it actually lends itself fairly easily to a singleton-like approach.
TransientRepository simply wrapps an instance of RepositoryIimpl, which
creates itself with a create() method. With some minor rework, this
multiple repository instance issue can be fixed and no client code will be
affected. Just a though though. I'll try sleeping and if that works, Im a
happy camper :-)
Thomas Mueller-6 wrote:
>
> Hi,
>
> I am also not happy with the way Repositories are opened, I think it
> would be better to have a Factory class and a method to open a
> repository with an URL. I hope this will be solved in the next JCR
> API.
>
> I also run into similar unpredictable cases where you have to re-try
> because the resource is sometimes still in use, however this is not
> repository related but 'delete a file':
>
> public static void delete(String fileName) throws Exception {
> File file = new File(fileName);
> if(file.exists()) {
> for(int i=0; i<16; i++) {
> boolean ok = file.delete();
> if(ok) {
> return;
> }
> System.gc();
> try {
> // sleep at most 256 ms
> Thread.sleep(i * i);
> } catch (InterruptedException e) {
> // ignore
> }
> }
> throw new Exception("Can't delete file");
> }
> }
>
> Maybe you can re-use part of this code (you should not try to delete
> the lock file, but try to open the repository in the loop).
>
> Thomas
>
>
>
> On 1/4/07, anton_slutsky <as...@applevac.com> wrote:
>>
>> I see your reasoning. However, if you look at the unit test I pasted in
>> the
>> earlier message, you'll see that the approach will not only prevent
>> another
>> process from creating a new repository, but will also stop this very same
>> process from getting a new instance. Please forgive me for being picky,
>> but
>> if you let people do "new", you really should make sure it works. Or
>> dont
>> let people create new instances and make the thing a singleton.
>>
>> My biggest issue is very simple. For some reason, my unit tests keep
>> crashing. I fork the VM on every unit test and do a shutdown() in every
>> tearDown(), for some reason, the .lock file lingers on sometimes and
>> breaks
>> the next test. This happens every time I run my test suite, but never in
>> the same place. I dont know what it is. Maybe its Windows taking too
>> long
>> to clean up. But my application is untestable. I can try running all
>> tests
>> in the same VM, but then my test state will become unpredictable as I
>> cache
>> things quite a bit.
>>
>>
>>
>> Tobias Bocanegra wrote:
>> >
>> > hmmm...view me previous answer (it somehow got lost):
>> >
>> > hi anton,
>> > we received many errors that were caused by multiple instances running
>> > on the same repository data that's why the .lock file is there to
>> > prevent 2 jackrabbit instances accessing the same physical data.
>> > actually, it should not cause any trouble, even if the jvm is killed
>> > or the repository is not shut down correctly.
>> > the mechanism works as follows: if the .lock file is present, the
>> > repository tries to acquire a java.nio.lock, and if this succeeds,
>> > only a warning is issued. if not, another process has locked the file
>> > and the repository startup is aborted. if the jvm is killed, it
>> > releases also the lock of on the .lock file.
>> >
>> > so i'm wondering what exact problems you see?
>> > regards, toby
>> >
>> > On 1/4/07, anton_slutsky <as...@applevac.com> wrote:
>> >>
>> >> Please look at the unit test below. This is basic usability. It's
>> not
>> >> working. Oddly enough, noone's even responding to the discussion. If
>> >> there
>> >> are issues with multi-repository usage, then let's address the issues
>> and
>> >> not hack a workaround. If you guys don't have time to work on this
>> one,
>> >> let's discuss the architecture of what needs to be done, and I'll be
>> more
>> >> then happy to help you out as we are in a bit of a bind with this one.
>> >>
>> >>
>> >> import junit.framework.TestCase;
>> >>
>> >> import javax.jcr.*;
>> >> import org.apache.jackrabbit.core.*;
>> >>
>> >> /**
>> >> * @author aslutsky
>> >> */
>> >> public class TestJackrabbit extends TestCase{
>> >>
>> >> public void testMultipleLogins()
>> >> throws Exception
>> >> {
>> >> Repository repo = new TransientRepository();
>> >> repo.login();
>> >>
>> >> repo = new TransientRepository();
>> >>
>> >> // this call will break. It'll complain of a .lock
>> file
>> >> locking the repository
>> >> // from another process. As you can see, this is the
>> >> only
>> >> process that's using the repository
>> >> // since the above call succeeded.
>> >> repo.login();
>> >>
>> >> }
>> >>
>> >> }
>> >>
>> >>
>> >>
>> >> anton_slutsky wrote:
>> >> >
>> >> > Hello,
>> >> >
>> >> > First of all, kudos on the great product. We are using it and love
>> it
>> >> > something awful. Having said that, one little "feature" that's
>> there
>> >> is
>> >> > extremely annoying. When a repo is instantiated, it creates a .lock
>> >> file
>> >> > at root (which you probably know all too well). I'm sure there is a
>> >> > reason for it to be there, and in prod it might even be a good idea
>> to
>> >> > make certain only one process access a given repository, but in
>> >> > development, this .lock file causes a world of grief. I'm using
>> >> > jackrabbit as a library for a web project running on jboss in dev
>> and
>> >> > websphere in prod. I constantly run into two major problems.
>> First,
>> >> > sometimes, I need to kill jboss, which negates any attempts at
>> >> finalize()
>> >> > logic I have implemented. Second, when redeploying, jboss seems to
>> >> ignore
>> >> > finalize() altogether when hot redeploying. Obviously, this is not
>> >> your
>> >> > issue, but it is a huge inconvenience for me and my team.
>> >> >
>> >> > I'm wondering if I were to submit a patch making this .lock logic
>> >> > configurable, how would it go with the team? Or are there
>> underlying
>> >> > architectural concerns that necessitate such an approach?
>> >> >
>> >> > Thanks!
>> >> > Anton
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160196
>> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > -----------------------------------------< tobias.bocanegra@day.com
>> >---
>> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
>> > T +41 61 226 98 98, F +41 61 226 98 97
>> > -----------------------------------------------< http://www.day.com
>> >---
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160735
>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8162109
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Jackrabbit repo locking
Posted by Tobias Bocanegra <to...@day.com>.
hi,
first of all i want to clarify some points:
1. the jackrabbit core repository is not designed to be started
multiple times on the _same_ physical datasource. i.e. in the same
repository home directory.
2. a clean shutdown of jackrabbit also unlocks and deletes the .lock
file (through: JackrabbitRepository.shutdown() )
3. if the repository is killed (eg. kill -9), the .lock file remains
but is not file-locked anymore. thus a subsequent repository startup
should not fail
4. The 'TransientRepository' was created to allow a very simple entry
point for users that want to play around with jackrabbit. if you need
more control of the repository creation and destruction use the
'RepositoryImpl.create()' method to initialize the repository:
RepositoryConfig config = RepositoryConfig.create(repositoryXml, homeDir);
JackrabbitRepository repo = RepositoryImpl.create(config);
...
...
repo.shutdown();
Actually the TransientRepository.shutdown() should shutdown of the
underlying repository as well. Can you file a JIRA issue and attach
your testcase? so we can investigate why your code is not working.
thanx.
regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: Jackrabbit repo locking
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
You are right, it doesn't work in every virtual machine. For example
JRockit may not collect the garbage. However it usually works in the
Sun VM. This loop is not supposed to be a 'clean' solution, it is a
hack hoping the resource will be freed in a finalizer. That's also why
the increasing delay is used. Anyway, this algorithm works when you
try to delete files in Windows if the application forgot to close the
file (FileOutputStream for example) but not references it any more.
I'm not sure if the algorithm works for Jackrabbit repositories that
where not closed, but it is worth a try I think.
Thomas
On 1/5/07, hanasaki <ha...@hanaden.com> wrote:
> Do you really want to call System.gc() that many times and inside a
> loop? On top of that, .gc is only a request. No guarantee that .gc
> takes place at all when called. Which is good because you used it in a
> loop ;)
>
> Thomas Mueller wrote:
> > Hi,
> >
> > I am also not happy with the way Repositories are opened, I think it
> > would be better to have a Factory class and a method to open a
> > repository with an URL. I hope this will be solved in the next JCR
> > API.
> >
> > I also run into similar unpredictable cases where you have to re-try
> > because the resource is sometimes still in use, however this is not
> > repository related but 'delete a file':
> >
> > public static void delete(String fileName) throws Exception {
> > File file = new File(fileName);
> > if(file.exists()) {
> > for(int i=0; i<16; i++) {
> > boolean ok = file.delete();
> > if(ok) {
> > return;
> > }
> > System.gc();
> > try {
> > // sleep at most 256 ms
> > Thread.sleep(i * i);
> > } catch (InterruptedException e) {
> > // ignore
> > }
> > }
> > throw new Exception("Can't delete file");
> > }
> > }
> >
> > Maybe you can re-use part of this code (you should not try to delete
> > the lock file, but try to open the repository in the loop).
> >
> > Thomas
> >
> >
> >
> > On 1/4/07, anton_slutsky <as...@applevac.com> wrote:
> >>
> >> I see your reasoning. However, if you look at the unit test I pasted
> >> in the
> >> earlier message, you'll see that the approach will not only prevent
> >> another
> >> process from creating a new repository, but will also stop this very same
> >> process from getting a new instance. Please forgive me for being
> >> picky, but
> >> if you let people do "new", you really should make sure it works. Or
> >> dont
> >> let people create new instances and make the thing a singleton.
> >>
> >> My biggest issue is very simple. For some reason, my unit tests keep
> >> crashing. I fork the VM on every unit test and do a shutdown() in every
> >> tearDown(), for some reason, the .lock file lingers on sometimes and
> >> breaks
> >> the next test. This happens every time I run my test suite, but never in
> >> the same place. I dont know what it is. Maybe its Windows taking too
> >> long
> >> to clean up. But my application is untestable. I can try running all
> >> tests
> >> in the same VM, but then my test state will become unpredictable as I
> >> cache
> >> things quite a bit.
> >>
> >>
> >>
> >> Tobias Bocanegra wrote:
> >> >
> >> > hmmm...view me previous answer (it somehow got lost):
> >> >
> >> > hi anton,
> >> > we received many errors that were caused by multiple instances running
> >> > on the same repository data that's why the .lock file is there to
> >> > prevent 2 jackrabbit instances accessing the same physical data.
> >> > actually, it should not cause any trouble, even if the jvm is killed
> >> > or the repository is not shut down correctly.
> >> > the mechanism works as follows: if the .lock file is present, the
> >> > repository tries to acquire a java.nio.lock, and if this succeeds,
> >> > only a warning is issued. if not, another process has locked the file
> >> > and the repository startup is aborted. if the jvm is killed, it
> >> > releases also the lock of on the .lock file.
> >> >
> >> > so i'm wondering what exact problems you see?
> >> > regards, toby
> >> >
> >> > On 1/4/07, anton_slutsky <as...@applevac.com> wrote:
> >> >>
> >> >> Please look at the unit test below. This is basic usability. It's
> >> not
> >> >> working. Oddly enough, noone's even responding to the discussion. If
> >> >> there
> >> >> are issues with multi-repository usage, then let's address the
> >> issues and
> >> >> not hack a workaround. If you guys don't have time to work on this
> >> one,
> >> >> let's discuss the architecture of what needs to be done, and I'll
> >> be more
> >> >> then happy to help you out as we are in a bit of a bind with this one.
> >> >>
> >> >>
> >> >> import junit.framework.TestCase;
> >> >>
> >> >> import javax.jcr.*;
> >> >> import org.apache.jackrabbit.core.*;
> >> >>
> >> >> /**
> >> >> * @author aslutsky
> >> >> */
> >> >> public class TestJackrabbit extends TestCase{
> >> >>
> >> >> public void testMultipleLogins()
> >> >> throws Exception
> >> >> {
> >> >> Repository repo = new TransientRepository();
> >> >> repo.login();
> >> >>
> >> >> repo = new TransientRepository();
> >> >>
> >> >> // this call will break. It'll complain of a .lock
> >> file
> >> >> locking the repository
> >> >> // from another process. As you can see, this is the
> >> >> only
> >> >> process that's using the repository
> >> >> // since the above call succeeded.
> >> >> repo.login();
> >> >>
> >> >> }
> >> >>
> >> >> }
> >> >>
> >> >>
> >> >>
> >> >> anton_slutsky wrote:
> >> >> >
> >> >> > Hello,
> >> >> >
> >> >> > First of all, kudos on the great product. We are using it and
> >> love it
> >> >> > something awful. Having said that, one little "feature" that's
> >> there
> >> >> is
> >> >> > extremely annoying. When a repo is instantiated, it creates a .lock
> >> >> file
> >> >> > at root (which you probably know all too well). I'm sure there is a
> >> >> > reason for it to be there, and in prod it might even be a good
> >> idea to
> >> >> > make certain only one process access a given repository, but in
> >> >> > development, this .lock file causes a world of grief. I'm using
> >> >> > jackrabbit as a library for a web project running on jboss in dev
> >> and
> >> >> > websphere in prod. I constantly run into two major problems.
> >> First,
> >> >> > sometimes, I need to kill jboss, which negates any attempts at
> >> >> finalize()
> >> >> > logic I have implemented. Second, when redeploying, jboss seems to
> >> >> ignore
> >> >> > finalize() altogether when hot redeploying. Obviously, this is not
> >> >> your
> >> >> > issue, but it is a huge inconvenience for me and my team.
> >> >> >
> >> >> > I'm wondering if I were to submit a patch making this .lock logic
> >> >> > configurable, how would it go with the team? Or are there
> >> underlying
> >> >> > architectural concerns that necessitate such an approach?
> >> >> >
> >> >> > Thanks!
> >> >> > Anton
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >> http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160196
> >> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > -----------------------------------------< tobias.bocanegra@day.com
> >> >---
> >> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> >> > T +41 61 226 98 98, F +41 61 226 98 97
> >> > -----------------------------------------------< http://www.day.com
> >> >---
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160735
> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >>
> >>
>
Re: Jackrabbit repo locking
Posted by hanasaki <ha...@hanaden.com>.
Do you really want to call System.gc() that many times and inside a
loop? On top of that, .gc is only a request. No guarantee that .gc
takes place at all when called. Which is good because you used it in a
loop ;)
Thomas Mueller wrote:
> Hi,
>
> I am also not happy with the way Repositories are opened, I think it
> would be better to have a Factory class and a method to open a
> repository with an URL. I hope this will be solved in the next JCR
> API.
>
> I also run into similar unpredictable cases where you have to re-try
> because the resource is sometimes still in use, however this is not
> repository related but 'delete a file':
>
> public static void delete(String fileName) throws Exception {
> File file = new File(fileName);
> if(file.exists()) {
> for(int i=0; i<16; i++) {
> boolean ok = file.delete();
> if(ok) {
> return;
> }
> System.gc();
> try {
> // sleep at most 256 ms
> Thread.sleep(i * i);
> } catch (InterruptedException e) {
> // ignore
> }
> }
> throw new Exception("Can't delete file");
> }
> }
>
> Maybe you can re-use part of this code (you should not try to delete
> the lock file, but try to open the repository in the loop).
>
> Thomas
>
>
>
> On 1/4/07, anton_slutsky <as...@applevac.com> wrote:
>>
>> I see your reasoning. However, if you look at the unit test I pasted
>> in the
>> earlier message, you'll see that the approach will not only prevent
>> another
>> process from creating a new repository, but will also stop this very same
>> process from getting a new instance. Please forgive me for being
>> picky, but
>> if you let people do "new", you really should make sure it works. Or
>> dont
>> let people create new instances and make the thing a singleton.
>>
>> My biggest issue is very simple. For some reason, my unit tests keep
>> crashing. I fork the VM on every unit test and do a shutdown() in every
>> tearDown(), for some reason, the .lock file lingers on sometimes and
>> breaks
>> the next test. This happens every time I run my test suite, but never in
>> the same place. I dont know what it is. Maybe its Windows taking too
>> long
>> to clean up. But my application is untestable. I can try running all
>> tests
>> in the same VM, but then my test state will become unpredictable as I
>> cache
>> things quite a bit.
>>
>>
>>
>> Tobias Bocanegra wrote:
>> >
>> > hmmm...view me previous answer (it somehow got lost):
>> >
>> > hi anton,
>> > we received many errors that were caused by multiple instances running
>> > on the same repository data that's why the .lock file is there to
>> > prevent 2 jackrabbit instances accessing the same physical data.
>> > actually, it should not cause any trouble, even if the jvm is killed
>> > or the repository is not shut down correctly.
>> > the mechanism works as follows: if the .lock file is present, the
>> > repository tries to acquire a java.nio.lock, and if this succeeds,
>> > only a warning is issued. if not, another process has locked the file
>> > and the repository startup is aborted. if the jvm is killed, it
>> > releases also the lock of on the .lock file.
>> >
>> > so i'm wondering what exact problems you see?
>> > regards, toby
>> >
>> > On 1/4/07, anton_slutsky <as...@applevac.com> wrote:
>> >>
>> >> Please look at the unit test below. This is basic usability. It's
>> not
>> >> working. Oddly enough, noone's even responding to the discussion. If
>> >> there
>> >> are issues with multi-repository usage, then let's address the
>> issues and
>> >> not hack a workaround. If you guys don't have time to work on this
>> one,
>> >> let's discuss the architecture of what needs to be done, and I'll
>> be more
>> >> then happy to help you out as we are in a bit of a bind with this one.
>> >>
>> >>
>> >> import junit.framework.TestCase;
>> >>
>> >> import javax.jcr.*;
>> >> import org.apache.jackrabbit.core.*;
>> >>
>> >> /**
>> >> * @author aslutsky
>> >> */
>> >> public class TestJackrabbit extends TestCase{
>> >>
>> >> public void testMultipleLogins()
>> >> throws Exception
>> >> {
>> >> Repository repo = new TransientRepository();
>> >> repo.login();
>> >>
>> >> repo = new TransientRepository();
>> >>
>> >> // this call will break. It'll complain of a .lock
>> file
>> >> locking the repository
>> >> // from another process. As you can see, this is the
>> >> only
>> >> process that's using the repository
>> >> // since the above call succeeded.
>> >> repo.login();
>> >>
>> >> }
>> >>
>> >> }
>> >>
>> >>
>> >>
>> >> anton_slutsky wrote:
>> >> >
>> >> > Hello,
>> >> >
>> >> > First of all, kudos on the great product. We are using it and
>> love it
>> >> > something awful. Having said that, one little "feature" that's
>> there
>> >> is
>> >> > extremely annoying. When a repo is instantiated, it creates a .lock
>> >> file
>> >> > at root (which you probably know all too well). I'm sure there is a
>> >> > reason for it to be there, and in prod it might even be a good
>> idea to
>> >> > make certain only one process access a given repository, but in
>> >> > development, this .lock file causes a world of grief. I'm using
>> >> > jackrabbit as a library for a web project running on jboss in dev
>> and
>> >> > websphere in prod. I constantly run into two major problems.
>> First,
>> >> > sometimes, I need to kill jboss, which negates any attempts at
>> >> finalize()
>> >> > logic I have implemented. Second, when redeploying, jboss seems to
>> >> ignore
>> >> > finalize() altogether when hot redeploying. Obviously, this is not
>> >> your
>> >> > issue, but it is a huge inconvenience for me and my team.
>> >> >
>> >> > I'm wondering if I were to submit a patch making this .lock logic
>> >> > configurable, how would it go with the team? Or are there
>> underlying
>> >> > architectural concerns that necessitate such an approach?
>> >> >
>> >> > Thanks!
>> >> > Anton
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160196
>> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > -----------------------------------------< tobias.bocanegra@day.com
>> >---
>> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
>> > T +41 61 226 98 98, F +41 61 226 98 97
>> > -----------------------------------------------< http://www.day.com
>> >---
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160735
>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>>
>>
Re: Jackrabbit repo locking
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
I am also not happy with the way Repositories are opened, I think it
would be better to have a Factory class and a method to open a
repository with an URL. I hope this will be solved in the next JCR
API.
I also run into similar unpredictable cases where you have to re-try
because the resource is sometimes still in use, however this is not
repository related but 'delete a file':
public static void delete(String fileName) throws Exception {
File file = new File(fileName);
if(file.exists()) {
for(int i=0; i<16; i++) {
boolean ok = file.delete();
if(ok) {
return;
}
System.gc();
try {
// sleep at most 256 ms
Thread.sleep(i * i);
} catch (InterruptedException e) {
// ignore
}
}
throw new Exception("Can't delete file");
}
}
Maybe you can re-use part of this code (you should not try to delete
the lock file, but try to open the repository in the loop).
Thomas
On 1/4/07, anton_slutsky <as...@applevac.com> wrote:
>
> I see your reasoning. However, if you look at the unit test I pasted in the
> earlier message, you'll see that the approach will not only prevent another
> process from creating a new repository, but will also stop this very same
> process from getting a new instance. Please forgive me for being picky, but
> if you let people do "new", you really should make sure it works. Or dont
> let people create new instances and make the thing a singleton.
>
> My biggest issue is very simple. For some reason, my unit tests keep
> crashing. I fork the VM on every unit test and do a shutdown() in every
> tearDown(), for some reason, the .lock file lingers on sometimes and breaks
> the next test. This happens every time I run my test suite, but never in
> the same place. I dont know what it is. Maybe its Windows taking too long
> to clean up. But my application is untestable. I can try running all tests
> in the same VM, but then my test state will become unpredictable as I cache
> things quite a bit.
>
>
>
> Tobias Bocanegra wrote:
> >
> > hmmm...view me previous answer (it somehow got lost):
> >
> > hi anton,
> > we received many errors that were caused by multiple instances running
> > on the same repository data that's why the .lock file is there to
> > prevent 2 jackrabbit instances accessing the same physical data.
> > actually, it should not cause any trouble, even if the jvm is killed
> > or the repository is not shut down correctly.
> > the mechanism works as follows: if the .lock file is present, the
> > repository tries to acquire a java.nio.lock, and if this succeeds,
> > only a warning is issued. if not, another process has locked the file
> > and the repository startup is aborted. if the jvm is killed, it
> > releases also the lock of on the .lock file.
> >
> > so i'm wondering what exact problems you see?
> > regards, toby
> >
> > On 1/4/07, anton_slutsky <as...@applevac.com> wrote:
> >>
> >> Please look at the unit test below. This is basic usability. It's not
> >> working. Oddly enough, noone's even responding to the discussion. If
> >> there
> >> are issues with multi-repository usage, then let's address the issues and
> >> not hack a workaround. If you guys don't have time to work on this one,
> >> let's discuss the architecture of what needs to be done, and I'll be more
> >> then happy to help you out as we are in a bit of a bind with this one.
> >>
> >>
> >> import junit.framework.TestCase;
> >>
> >> import javax.jcr.*;
> >> import org.apache.jackrabbit.core.*;
> >>
> >> /**
> >> * @author aslutsky
> >> */
> >> public class TestJackrabbit extends TestCase{
> >>
> >> public void testMultipleLogins()
> >> throws Exception
> >> {
> >> Repository repo = new TransientRepository();
> >> repo.login();
> >>
> >> repo = new TransientRepository();
> >>
> >> // this call will break. It'll complain of a .lock file
> >> locking the repository
> >> // from another process. As you can see, this is the
> >> only
> >> process that's using the repository
> >> // since the above call succeeded.
> >> repo.login();
> >>
> >> }
> >>
> >> }
> >>
> >>
> >>
> >> anton_slutsky wrote:
> >> >
> >> > Hello,
> >> >
> >> > First of all, kudos on the great product. We are using it and love it
> >> > something awful. Having said that, one little "feature" that's there
> >> is
> >> > extremely annoying. When a repo is instantiated, it creates a .lock
> >> file
> >> > at root (which you probably know all too well). I'm sure there is a
> >> > reason for it to be there, and in prod it might even be a good idea to
> >> > make certain only one process access a given repository, but in
> >> > development, this .lock file causes a world of grief. I'm using
> >> > jackrabbit as a library for a web project running on jboss in dev and
> >> > websphere in prod. I constantly run into two major problems. First,
> >> > sometimes, I need to kill jboss, which negates any attempts at
> >> finalize()
> >> > logic I have implemented. Second, when redeploying, jboss seems to
> >> ignore
> >> > finalize() altogether when hot redeploying. Obviously, this is not
> >> your
> >> > issue, but it is a huge inconvenience for me and my team.
> >> >
> >> > I'm wondering if I were to submit a patch making this .lock logic
> >> > configurable, how would it go with the team? Or are there underlying
> >> > architectural concerns that necessitate such an approach?
> >> >
> >> > Thanks!
> >> > Anton
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160196
> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > -----------------------------------------< tobias.bocanegra@day.com >---
> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> > T +41 61 226 98 98, F +41 61 226 98 97
> > -----------------------------------------------< http://www.day.com >---
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160735
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Re: Jackrabbit repo locking
Posted by anton_slutsky <as...@applevac.com>.
I see your reasoning. However, if you look at the unit test I pasted in the
earlier message, you'll see that the approach will not only prevent another
process from creating a new repository, but will also stop this very same
process from getting a new instance. Please forgive me for being picky, but
if you let people do "new", you really should make sure it works. Or dont
let people create new instances and make the thing a singleton.
My biggest issue is very simple. For some reason, my unit tests keep
crashing. I fork the VM on every unit test and do a shutdown() in every
tearDown(), for some reason, the .lock file lingers on sometimes and breaks
the next test. This happens every time I run my test suite, but never in
the same place. I dont know what it is. Maybe its Windows taking too long
to clean up. But my application is untestable. I can try running all tests
in the same VM, but then my test state will become unpredictable as I cache
things quite a bit.
Tobias Bocanegra wrote:
>
> hmmm...view me previous answer (it somehow got lost):
>
> hi anton,
> we received many errors that were caused by multiple instances running
> on the same repository data that's why the .lock file is there to
> prevent 2 jackrabbit instances accessing the same physical data.
> actually, it should not cause any trouble, even if the jvm is killed
> or the repository is not shut down correctly.
> the mechanism works as follows: if the .lock file is present, the
> repository tries to acquire a java.nio.lock, and if this succeeds,
> only a warning is issued. if not, another process has locked the file
> and the repository startup is aborted. if the jvm is killed, it
> releases also the lock of on the .lock file.
>
> so i'm wondering what exact problems you see?
> regards, toby
>
> On 1/4/07, anton_slutsky <as...@applevac.com> wrote:
>>
>> Please look at the unit test below. This is basic usability. It's not
>> working. Oddly enough, noone's even responding to the discussion. If
>> there
>> are issues with multi-repository usage, then let's address the issues and
>> not hack a workaround. If you guys don't have time to work on this one,
>> let's discuss the architecture of what needs to be done, and I'll be more
>> then happy to help you out as we are in a bit of a bind with this one.
>>
>>
>> import junit.framework.TestCase;
>>
>> import javax.jcr.*;
>> import org.apache.jackrabbit.core.*;
>>
>> /**
>> * @author aslutsky
>> */
>> public class TestJackrabbit extends TestCase{
>>
>> public void testMultipleLogins()
>> throws Exception
>> {
>> Repository repo = new TransientRepository();
>> repo.login();
>>
>> repo = new TransientRepository();
>>
>> // this call will break. It'll complain of a .lock file
>> locking the repository
>> // from another process. As you can see, this is the
>> only
>> process that's using the repository
>> // since the above call succeeded.
>> repo.login();
>>
>> }
>>
>> }
>>
>>
>>
>> anton_slutsky wrote:
>> >
>> > Hello,
>> >
>> > First of all, kudos on the great product. We are using it and love it
>> > something awful. Having said that, one little "feature" that's there
>> is
>> > extremely annoying. When a repo is instantiated, it creates a .lock
>> file
>> > at root (which you probably know all too well). I'm sure there is a
>> > reason for it to be there, and in prod it might even be a good idea to
>> > make certain only one process access a given repository, but in
>> > development, this .lock file causes a world of grief. I'm using
>> > jackrabbit as a library for a web project running on jboss in dev and
>> > websphere in prod. I constantly run into two major problems. First,
>> > sometimes, I need to kill jboss, which negates any attempts at
>> finalize()
>> > logic I have implemented. Second, when redeploying, jboss seems to
>> ignore
>> > finalize() altogether when hot redeploying. Obviously, this is not
>> your
>> > issue, but it is a huge inconvenience for me and my team.
>> >
>> > I'm wondering if I were to submit a patch making this .lock logic
>> > configurable, how would it go with the team? Or are there underlying
>> > architectural concerns that necessitate such an approach?
>> >
>> > Thanks!
>> > Anton
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160196
>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>
>
--
View this message in context: http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160735
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Jackrabbit repo locking
Posted by Tobias Bocanegra <to...@day.com>.
hmmm...view me previous answer (it somehow got lost):
hi anton,
we received many errors that were caused by multiple instances running
on the same repository data that's why the .lock file is there to
prevent 2 jackrabbit instances accessing the same physical data.
actually, it should not cause any trouble, even if the jvm is killed
or the repository is not shut down correctly.
the mechanism works as follows: if the .lock file is present, the
repository tries to acquire a java.nio.lock, and if this succeeds,
only a warning is issued. if not, another process has locked the file
and the repository startup is aborted. if the jvm is killed, it
releases also the lock of on the .lock file.
so i'm wondering what exact problems you see?
regards, toby
On 1/4/07, anton_slutsky <as...@applevac.com> wrote:
>
> Please look at the unit test below. This is basic usability. It's not
> working. Oddly enough, noone's even responding to the discussion. If there
> are issues with multi-repository usage, then let's address the issues and
> not hack a workaround. If you guys don't have time to work on this one,
> let's discuss the architecture of what needs to be done, and I'll be more
> then happy to help you out as we are in a bit of a bind with this one.
>
>
> import junit.framework.TestCase;
>
> import javax.jcr.*;
> import org.apache.jackrabbit.core.*;
>
> /**
> * @author aslutsky
> */
> public class TestJackrabbit extends TestCase{
>
> public void testMultipleLogins()
> throws Exception
> {
> Repository repo = new TransientRepository();
> repo.login();
>
> repo = new TransientRepository();
>
> // this call will break. It'll complain of a .lock file
> locking the repository
> // from another process. As you can see, this is the only
> process that's using the repository
> // since the above call succeeded.
> repo.login();
>
> }
>
> }
>
>
>
> anton_slutsky wrote:
> >
> > Hello,
> >
> > First of all, kudos on the great product. We are using it and love it
> > something awful. Having said that, one little "feature" that's there is
> > extremely annoying. When a repo is instantiated, it creates a .lock file
> > at root (which you probably know all too well). I'm sure there is a
> > reason for it to be there, and in prod it might even be a good idea to
> > make certain only one process access a given repository, but in
> > development, this .lock file causes a world of grief. I'm using
> > jackrabbit as a library for a web project running on jboss in dev and
> > websphere in prod. I constantly run into two major problems. First,
> > sometimes, I need to kill jboss, which negates any attempts at finalize()
> > logic I have implemented. Second, when redeploying, jboss seems to ignore
> > finalize() altogether when hot redeploying. Obviously, this is not your
> > issue, but it is a huge inconvenience for me and my team.
> >
> > I'm wondering if I were to submit a patch making this .lock logic
> > configurable, how would it go with the team? Or are there underlying
> > architectural concerns that necessitate such an approach?
> >
> > Thanks!
> > Anton
> >
>
> --
> View this message in context: http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160196
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: Jackrabbit repo locking
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
The problem is (as far as I understand it) that only one process may
open the repository at any time. This is also the case for most
databases (there are some exceptions, for example Microsoft Access). I
think this is an architectural decision, and in my view, it is the
right decision to let the repository only be accessed from one process
(this is just my view) because it improves performance and simplifies
the design.
I'm not sure, do you want the feature 'allow concurrent access to the
same repository from multiple processes'? Or are you OK with this, and
want to solve the problem you are running into with the unclosed
repository?
Thomas
On 1/4/07, anton_slutsky <as...@applevac.com> wrote:
>
> Please look at the unit test below. This is basic usability. It's not
> working. Oddly enough, noone's even responding to the discussion. If there
> are issues with multi-repository usage, then let's address the issues and
> not hack a workaround. If you guys don't have time to work on this one,
> let's discuss the architecture of what needs to be done, and I'll be more
> then happy to help you out as we are in a bit of a bind with this one.
>
>
> import junit.framework.TestCase;
>
> import javax.jcr.*;
> import org.apache.jackrabbit.core.*;
>
> /**
> * @author aslutsky
> */
> public class TestJackrabbit extends TestCase{
>
> public void testMultipleLogins()
> throws Exception
> {
> Repository repo = new TransientRepository();
> repo.login();
>
> repo = new TransientRepository();
>
> // this call will break. It'll complain of a .lock file
> locking the repository
> // from another process. As you can see, this is the only
> process that's using the repository
> // since the above call succeeded.
> repo.login();
>
> }
>
> }
>
>
>
> anton_slutsky wrote:
> >
> > Hello,
> >
> > First of all, kudos on the great product. We are using it and love it
> > something awful. Having said that, one little "feature" that's there is
> > extremely annoying. When a repo is instantiated, it creates a .lock file
> > at root (which you probably know all too well). I'm sure there is a
> > reason for it to be there, and in prod it might even be a good idea to
> > make certain only one process access a given repository, but in
> > development, this .lock file causes a world of grief. I'm using
> > jackrabbit as a library for a web project running on jboss in dev and
> > websphere in prod. I constantly run into two major problems. First,
> > sometimes, I need to kill jboss, which negates any attempts at finalize()
> > logic I have implemented. Second, when redeploying, jboss seems to ignore
> > finalize() altogether when hot redeploying. Obviously, this is not your
> > issue, but it is a huge inconvenience for me and my team.
> >
> > I'm wondering if I were to submit a patch making this .lock logic
> > configurable, how would it go with the team? Or are there underlying
> > architectural concerns that necessitate such an approach?
> >
> > Thanks!
> > Anton
> >
>
> --
> View this message in context: http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160196
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Re: Jackrabbit repo locking
Posted by anton_slutsky <as...@applevac.com>.
Please look at the unit test below. This is basic usability. It's not
working. Oddly enough, noone's even responding to the discussion. If there
are issues with multi-repository usage, then let's address the issues and
not hack a workaround. If you guys don't have time to work on this one,
let's discuss the architecture of what needs to be done, and I'll be more
then happy to help you out as we are in a bit of a bind with this one.
import junit.framework.TestCase;
import javax.jcr.*;
import org.apache.jackrabbit.core.*;
/**
* @author aslutsky
*/
public class TestJackrabbit extends TestCase{
public void testMultipleLogins()
throws Exception
{
Repository repo = new TransientRepository();
repo.login();
repo = new TransientRepository();
// this call will break. It'll complain of a .lock file
locking the repository
// from another process. As you can see, this is the only
process that's using the repository
// since the above call succeeded.
repo.login();
}
}
anton_slutsky wrote:
>
> Hello,
>
> First of all, kudos on the great product. We are using it and love it
> something awful. Having said that, one little "feature" that's there is
> extremely annoying. When a repo is instantiated, it creates a .lock file
> at root (which you probably know all too well). I'm sure there is a
> reason for it to be there, and in prod it might even be a good idea to
> make certain only one process access a given repository, but in
> development, this .lock file causes a world of grief. I'm using
> jackrabbit as a library for a web project running on jboss in dev and
> websphere in prod. I constantly run into two major problems. First,
> sometimes, I need to kill jboss, which negates any attempts at finalize()
> logic I have implemented. Second, when redeploying, jboss seems to ignore
> finalize() altogether when hot redeploying. Obviously, this is not your
> issue, but it is a huge inconvenience for me and my team.
>
> I'm wondering if I were to submit a patch making this .lock logic
> configurable, how would it go with the team? Or are there underlying
> architectural concerns that necessitate such an approach?
>
> Thanks!
> Anton
>
--
View this message in context: http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a8160196
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.