You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Daniel Bruen <db...@saltation.de> on 2007/08/22 17:37:49 UTC
Repository Lock Problem in JEE-Environment
Hi again!
I am using jackrabbit-1.3.1 as a custom resource in glassfish and access
the repository from a stateless session bean (EJB3) via jndi. No problem
so far. When I try to redeploy my bean the repository-lock is not
removed. I have to restart the application server, then it works again.
I see that this is mainly a problem of the JEE-container, but there must
be a solution for this. In EJB3 there is no finalize()-Method anymore in
which I could do a shutdown... any hints?
Cheers,
Dan
Re: Repository Lock Problem in JEE-Environment
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
When I try to redeploy my bean the repository-lock is not
> removed.
So the repository is still open.
> but there must
> be a solution for this.
Is there no way to close the repository in your application?
In EJB3 there is no finalize()-Method anymore in
> which I could do a shutdown...
In some virtual machines (JRockit) finalize() is called very later. I
wouldn't rely on finalizer (even in other environments).
Thomas
Re: Repository Lock Problem in JEE-Environment
Posted by Daniel Bruen <db...@saltation.de>.
Hi!
It really seems to be a glassfish V1-related problem and the
model-2-deployment described for glassfish in the wiki is certainly not
the correct way to go (connector-deployment using the rar-file seems
better, although I wasn't able to get it to work yet).
Anybody else using Glassfish V1 (Sun Java System Application Server) and
jackrabbit?
Cheers,
Dan
Markus Reis schrieb:
> Hi,
>
>
> I can only support what Hendrik says - I'm accessing the Jackrabbit
> repository (deployment model 2) parallel from both a JSF application and
> an EJB3 (using the context lookup in order to get the repository handle
> in both scenarios) ...
> ... my environment is (however): JBoss 4.0.5GA, Jackrabbit 1.3.1, Java
> 1.5_06.
>
>
> kind regards,
> Markus
>
>
> Hendrik Beck (camunda) schrieb:
>> Sorry, must have been a bit trigger-happy... ;-)
>>
>> Again: ----->
>>
>> Hi Daniel (and also Markus, nice to see you, too ;-) )!
>>
>> I haven't experienced your problem although I am using it in a similar
>> manner. But could it be related to this one here:
>>
>> http://issues.apache.org/jira/browse/JCR-912
>>
>>
>> It sounds a little bit like to me, although I am not really into the
>> actual
>> codebase and stuff...
>>
>>
>> Cheers
>> Hendrik
>>
>>
>>
>>> -----Original Message-----
>>> From: news [mailto:news@sea.gmane.org] On Behalf Of Daniel Br?uen
>>> Sent: Friday, August 24, 2007 4:42 PM
>>> To: users@jackrabbit.apache.org
>>> Subject: Re: Repository Lock Problem in JEE-Environment
>>>
>>> Hi Hendrik!
>>>
>>>
>>> Hendrik Beck (camunda) schrieb:
>>>
>>>
>>>> What deployment model do you use? Or do you start and shutdown the
>>>> repository by your own application, e.g. in your beans?
>>>>
>>> I am using the shared deployment model and I have registered the jcr as
>>> a custom JNDI-Resource in glassfish (exactly the way it is described in
>>> the wiki). In my beans I simply do something like
>>>
>>> InitialContext ctx = new InitialContext();
>>> rep = (Repository) ctx.lookup("jcr/repository");
>>>
>>> or use the @Resource annotation.
>>>
>>> Both ways I regularly get messages like
>>> "javax.jcr.RepositoryException: The repository home
>>> /opt/jackrabbit/repository appears to be already locked by the current
>>> process."
>>>
>>> This message appears whenever I allow the system to idle for a while, or
>>> on redeploy of my bean.
>>>
>>> Cheers,
>>> Dan
>>>
>>
>>
>>
>
>
Re: Repository Lock Problem in JEE-Environment
Posted by Markus Reis <ma...@researchstudio.at>.
Hi,
I can only support what Hendrik says - I'm accessing the Jackrabbit
repository (deployment model 2) parallel from both a JSF application and
an EJB3 (using the context lookup in order to get the repository handle
in both scenarios) ...
... my environment is (however): JBoss 4.0.5GA, Jackrabbit 1.3.1, Java
1.5_06.
kind regards,
Markus
Hendrik Beck (camunda) schrieb:
> Sorry, must have been a bit trigger-happy... ;-)
>
> Again: ----->
>
> Hi Daniel (and also Markus, nice to see you, too ;-) )!
>
> I haven't experienced your problem although I am using it in a similar
> manner. But could it be related to this one here:
>
> http://issues.apache.org/jira/browse/JCR-912
>
>
> It sounds a little bit like to me, although I am not really into the actual
> codebase and stuff...
>
>
> Cheers
> Hendrik
>
>
>
>> -----Original Message-----
>> From: news [mailto:news@sea.gmane.org] On Behalf Of Daniel Br?uen
>> Sent: Friday, August 24, 2007 4:42 PM
>> To: users@jackrabbit.apache.org
>> Subject: Re: Repository Lock Problem in JEE-Environment
>>
>> Hi Hendrik!
>>
>>
>> Hendrik Beck (camunda) schrieb:
>>
>>
>>> What deployment model do you use? Or do you start and shutdown the
>>> repository by your own application, e.g. in your beans?
>>>
>> I am using the shared deployment model and I have registered the jcr as
>> a custom JNDI-Resource in glassfish (exactly the way it is described in
>> the wiki). In my beans I simply do something like
>>
>> InitialContext ctx = new InitialContext();
>> rep = (Repository) ctx.lookup("jcr/repository");
>>
>> or use the @Resource annotation.
>>
>> Both ways I regularly get messages like
>> "javax.jcr.RepositoryException: The repository home
>> /opt/jackrabbit/repository appears to be already locked by the current
>> process."
>>
>> This message appears whenever I allow the system to idle for a while, or
>> on redeploy of my bean.
>>
>> Cheers,
>> Dan
>>
>
>
>
--
Mag. Markus Reis
Austrian Research Centers GmbH - ARC
Research Studios
Studio Digital Memory Engineering
Thurngasse 8/3/20, A-1090 Wien
Mobile: +43 664 825 1106
Tel.: +43-1-585 05 37 - 16
Fax: +43-1-585 37 41
<ma...@researchstudio.at>
http://www.arcs.ac.at/
http://www.researchstudio.at/
http://dme.researchstudio.at/
HG Wien – FN 115980i – ATU14703506
RE: Repository Lock Problem in JEE-Environment
Posted by "Hendrik Beck (camunda)" <he...@camunda.com>.
Sorry, must have been a bit trigger-happy... ;-)
Again: ----->
Hi Daniel (and also Markus, nice to see you, too ;-) )!
I haven't experienced your problem although I am using it in a similar
manner. But could it be related to this one here:
http://issues.apache.org/jira/browse/JCR-912
It sounds a little bit like to me, although I am not really into the actual
codebase and stuff...
Cheers
Hendrik
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Daniel Br?uen
> Sent: Friday, August 24, 2007 4:42 PM
> To: users@jackrabbit.apache.org
> Subject: Re: Repository Lock Problem in JEE-Environment
>
> Hi Hendrik!
>
>
> Hendrik Beck (camunda) schrieb:
>
> > What deployment model do you use? Or do you start and shutdown the
> > repository by your own application, e.g. in your beans?
>
> I am using the shared deployment model and I have registered the jcr as
> a custom JNDI-Resource in glassfish (exactly the way it is described in
> the wiki). In my beans I simply do something like
>
> InitialContext ctx = new InitialContext();
> rep = (Repository) ctx.lookup("jcr/repository");
>
> or use the @Resource annotation.
>
> Both ways I regularly get messages like
> "javax.jcr.RepositoryException: The repository home
> /opt/jackrabbit/repository appears to be already locked by the current
> process."
>
> This message appears whenever I allow the system to idle for a while, or
> on redeploy of my bean.
>
> Cheers,
> Dan
RE: Repository Lock Problem in JEE-Environment
Posted by "Hendrik Beck (camunda)" <he...@camunda.com>.
Hi Daniel (and also Markus, nice to see you, too ;-) )!
I haven't experienced your problem although I am using it in a similar
manner. But could it be related to this one here:
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Daniel Br?uen
> Sent: Friday, August 24, 2007 4:42 PM
> To: users@jackrabbit.apache.org
> Subject: Re: Repository Lock Problem in JEE-Environment
>
> Hi Hendrik!
>
>
> Hendrik Beck (camunda) schrieb:
>
> > What deployment model do you use? Or do you start and shutdown the
> > repository by your own application, e.g. in your beans?
>
> I am using the shared deployment model and I have registered the jcr as
> a custom JNDI-Resource in glassfish (exactly the way it is described in
> the wiki). In my beans I simply do something like
>
> InitialContext ctx = new InitialContext();
> rep = (Repository) ctx.lookup("jcr/repository");
>
> or use the @Resource annotation.
>
> Both ways I regularly get messages like
> "javax.jcr.RepositoryException: The repository home
> /opt/jackrabbit/repository appears to be already locked by the current
> process."
>
> This message appears whenever I allow the system to idle for a while, or
> on redeploy of my bean.
>
> Cheers,
> Dan
Re: Repository Lock Problem in JEE-Environment
Posted by Daniel Bruen <db...@saltation.de>.
Hi Hendrik!
Hendrik Beck (camunda) schrieb:
> What deployment model do you use? Or do you start and shutdown the
> repository by your own application, e.g. in your beans?
I am using the shared deployment model and I have registered the jcr as
a custom JNDI-Resource in glassfish (exactly the way it is described in
the wiki). In my beans I simply do something like
InitialContext ctx = new InitialContext();
rep = (Repository) ctx.lookup("jcr/repository");
or use the @Resource annotation.
Both ways I regularly get messages like
"javax.jcr.RepositoryException: The repository home
/opt/jackrabbit/repository appears to be already locked by the current
process."
This message appears whenever I allow the system to idle for a while, or
on redeploy of my bean.
Cheers,
Dan
RE: Repository Lock Problem in JEE-Environment
Posted by "Hendrik Beck (camunda)" <he...@camunda.com>.
Hi Dan!
Wait, I am not 100% sure what we are talking about here. I would see it like
that:
- One instance of Jackrabbit is allowed to access the repository (i.e. the
physical storage of the repository) at a time. That's why the repository is
locked by that instance e.g. by setting the .lock file
- This instance of Jackrabbit has to be started somehow. Depending on your
deployment model (http://jackrabbit.apache.org/doc/deploy.html) this is done
in different ways. I assumed that you use model 2 which means that
Jackrabbit is started at container startup and then registered into JNDI.
- If you now access it via JNDI you get a reference to the repository, login
into that repository and then get a session handle back. This can be done by
multiple beans / applications the same time
What deployment model do you use? Or do you start and shutdown the
repository by your own application, e.g. in your beans?
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Daniel Br?uen
> Sent: Friday, August 24, 2007 2:50 PM
> To: users@jackrabbit.apache.org
> Subject: Re: Repository Lock Problem in JEE-Environment
>
> Hi Hendrik!
>
> Hendrik Beck (camunda) wrote:
> >
> > @Resource (name="jcr/local") private Repository repository;
> >
> > (...)
> >
>
> Yes, I have done that already.... but it does not help if two
> bean-instances are created, because the second bean is not able to get
> the repository via jndi (because the repository is already locked).
>
> Furthermore whenever I do not call shutdown() explicitly I have to rely
> on the Garbage Collector to unlock my repository.
>
> I am sure there is something in this entiry concept that I am missing...
> otherwise the whole thing would not make that much sense at all!
>
> Cheers,
> Dan
Re: Repository Lock Problem in JEE-Environment
Posted by Daniel Bruen <db...@saltation.de>.
Hi Hendrik!
Hendrik Beck (camunda) wrote:
>
> @Resource (name="jcr/local") private Repository repository;
>
> (...)
>
Yes, I have done that already.... but it does not help if two
bean-instances are created, because the second bean is not able to get
the repository via jndi (because the repository is already locked).
Furthermore whenever I do not call shutdown() explicitly I have to rely
on the Garbage Collector to unlock my repository.
I am sure there is something in this entiry concept that I am missing...
otherwise the whole thing would not make that much sense at all!
Cheers,
Dan
Re: Repository Lock Problem in JEE-Environment
Posted by Markus Reis <ma...@researchstudio.at>.
Hi Dan (Hi Hendrik - nice to "see" you here),
I've posted example code that may help in the thread "Re: [Re: Re: JBoss
and Jackrabbit JCA]" on Aug 17th (12:19).
kind regards,
Markus
Hendrik Beck (camunda) schrieb:
> Hi Dan!
>
>
>> -----Original Message-----
>> From: news [mailto:news@sea.gmane.org] On Behalf Of Daniel Br?uen
>> Sent: Thursday, August 23, 2007 10:23 PM
>> To: users@jackrabbit.apache.org
>> Subject: Re: Repository Lock Problem in JEE-Environment
>>
>> Hi!
>>
>> Marcel May wrote:
>>
>>> Can you use |@PreDestroy annotated method ?
>>>
>> Yes, that's worth a try, at least for stateful session beans
>> (@PrePassivate, @PostPassivate).
>>
>
> Be aware, that you should not rely on that these methods are really called
> in any case. One example would be a server crash, but in general you should
> be careful with that. Just ask yourself the question how serious it would be
> if your bean dies without having executed the code in here.
>
>
>
>> How do other folks use Jackrabbit in a JEE Environment, especially in a
>> session bean? Do you acquire the repository in every single method call
>> via JNDI, or do you store the repository handle in a member variable of
>> the bean?
>>
>> If I get it correctly there can be only one single bean accessing the
>> repository, since the repository can talk to only one single
>> application. As a consequence there would be a locking-problem if the
>> container decides to create another bean to handle requests, which is odd.
>>
>
>
> I haven't tested it, but the @Resource annotation should work to access
> anything that's in JNDI. For example if you hooked your Repository into JNDI
> under "java:jcr/local" then you should be able to get the handle like that:
>
>
> public class MyBean() {
>
> @Resource (name="jcr/local") private Repository repository;
>
> (...)
>
> }
>
> The container now looks up the Repository in JNDI and injects it into the
> bean when it's created. This should work with managed beans in EJB3 (i.e. SL
> and SF beans), I doubt it's working e.g. for helper classes.
>
>
>
> Hope it helps. Best regards
> Hendrik
>
>
>
>
>
>> cheers,
>> Dan
>>
>
>
>
--
Mag. Markus Reis
Austrian Research Centers GmbH - ARC
Research Studios
Studio Digital Memory Engineering
Thurngasse 8/3/20, A-1090 Wien
Mobile: +43 664 825 1106
Tel.: +43-1-585 05 37 - 16
Fax: +43-1-585 37 41
<ma...@researchstudio.at>
http://www.arcs.ac.at/
http://www.researchstudio.at/
http://dme.researchstudio.at/
HG Wien – FN 115980i – ATU14703506
RE: Repository Lock Problem in JEE-Environment
Posted by "Hendrik Beck (camunda)" <he...@camunda.com>.
Hi Dan!
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Daniel Br?uen
> Sent: Thursday, August 23, 2007 10:23 PM
> To: users@jackrabbit.apache.org
> Subject: Re: Repository Lock Problem in JEE-Environment
>
> Hi!
>
> Marcel May wrote:
> > Can you use |@PreDestroy annotated method ?
>
> Yes, that's worth a try, at least for stateful session beans
> (@PrePassivate, @PostPassivate).
Be aware, that you should not rely on that these methods are really called
in any case. One example would be a server crash, but in general you should
be careful with that. Just ask yourself the question how serious it would be
if your bean dies without having executed the code in here.
>
> How do other folks use Jackrabbit in a JEE Environment, especially in a
> session bean? Do you acquire the repository in every single method call
> via JNDI, or do you store the repository handle in a member variable of
> the bean?
>
> If I get it correctly there can be only one single bean accessing the
> repository, since the repository can talk to only one single
> application. As a consequence there would be a locking-problem if the
> container decides to create another bean to handle requests, which is odd.
I haven't tested it, but the @Resource annotation should work to access
anything that's in JNDI. For example if you hooked your Repository into JNDI
under "java:jcr/local" then you should be able to get the handle like that:
public class MyBean() {
@Resource (name="jcr/local") private Repository repository;
(...)
}
The container now looks up the Repository in JNDI and injects it into the
bean when it's created. This should work with managed beans in EJB3 (i.e. SL
and SF beans), I doubt it's working e.g. for helper classes.
Hope it helps. Best regards
Hendrik
>
> cheers,
> Dan
Re: Repository Lock Problem in JEE-Environment
Posted by Daniel Bruen <db...@saltation.de>.
Hi!
Marcel May wrote:
> Can you use |@PreDestroy annotated method ?
Yes, that's worth a try, at least for stateful session beans
(@PrePassivate, @PostPassivate).
How do other folks use Jackrabbit in a JEE Environment, especially in a
session bean? Do you acquire the repository in every single method call
via JNDI, or do you store the repository handle in a member variable of
the bean?
If I get it correctly there can be only one single bean accessing the
repository, since the repository can talk to only one single
application. As a consequence there would be a locking-problem if the
container decides to create another bean to handle requests, which is odd.
cheers,
Dan
Re: Repository Lock Problem in JEE-Environment
Posted by Marcel May <ma...@consol.de>.
Can you use |@PreDestroy annotated method ?
|
Daniel Bruen wrote:
> Hi again!
>
> I am using jackrabbit-1.3.1 as a custom resource in glassfish and
> access the repository from a stateless session bean (EJB3) via jndi.
> No problem so far. When I try to redeploy my bean the repository-lock
> is not removed. I have to restart the application server, then it
> works again. I see that this is mainly a problem of the JEE-container,
> but there must be a solution for this. In EJB3 there is no
> finalize()-Method anymore in which I could do a shutdown... any hints?
>
> Cheers,
> Dan
>