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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
>> >>
>> >>
>> >
>> >
>> > --
>> > -----------------------------------------< [EMAIL PROTECTED]
>> >---
>> > 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.
