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 <[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.
