You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by "Boni Gopalan (BioImagene)" <Bo...@bioimagene.com> on 2008/11/24 09:59:42 UTC
Posts on JCR and Jackrabbit
http://whiteboardjunkie.wordpress.com/
I am writing a series of posts on using JCR in enterprise applications.
I started writing yesterday. As of now most of the posts are
rudimentary in nature. Please point out mistakes and areas of
improvement.
Thanks
boni
Boni Gopalan
Manager Engineering
BioImagene, Pune
+91-206-609-6579(O)
+91-992-369-9356(C)
Re: Posts on JCR and Jackrabbit
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Nov 24, 2008 at 12:42 PM, Boni Gopalan (BioImagene)
<Bo...@bioimagene.com> wrote:
> Does jackrabbit have a session pool functionality?
No, not currently.
See [1] for a good discussion (at sling-dev@) of potential surprises
with session pools. I agree with Tobias in that a session pool should
ideally be implemented inside Jackrabbit instead of on top of it.
[1] http://markmail.org/message/jwki4djsv3rcuzct
BR,
Jukka Zitting
RE: Posts on JCR and Jackrabbit
Posted by "Boni Gopalan (BioImagene)" <Bo...@bioimagene.com>.
Jukka:
You are right on both counts. I could directly index the map with UUID
to remove a layer of complexity and If user forgets to call
RepositoryUtil.logout(sessionId) the gc will never do the magic of
releasing the session resources. I could prevent this by just not
keeping the currentSessions map. Since I am not doing any pooling logic
in the current version I feel it is worthwhile to not to complicate
things yet. I will refactor the code.
Does jackrabbit have a session pool functionality?
Thanks
Boni
-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
Sent: 24 November 2008 16:36
To: users@jackrabbit.apache.org
Subject: Re: Posts on JCR and Jackrabbit
Hi,
On Mon, Nov 24, 2008 at 11:47 AM, Boni Gopalan (BioImagene)
<Bo...@bioimagene.com> wrote:
> RepositoryUtil.logout(...) takes in parameter 'String sessionId' , not
> 'String userName'. SessionID is an UUID generated and mapped into
> SessionWrapper.
Ah, you're right. I was mislead by the keying of the session map by
the username. Why not key it directly with the UUID?
> different ) is tested. RepositoryUtil, as such will evolve as I build
> through the application. Currently, each call to login() will return
a
> unique SessionWrapper and as per implementation the application can
> either call logout() to release the resources or the resource
releasing
> will happen when VM invokes finalize() on the SessionWrapper. I will
> not call the finalize() strategy robust but that is what I have now
:-)
OK, Jackrabbit currently doesn't use finalize().
However, aren't there references in RepositoryUtil to all
SessionWrapper instances, preventing them from being garbage
collected? Note that finalize() is by default *not* run when the VM
exits; it's only run before an instance is collected as garbage.
BR,
Jukka Zitting
Re: Posts on JCR and Jackrabbit
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Nov 24, 2008 at 11:47 AM, Boni Gopalan (BioImagene)
<Bo...@bioimagene.com> wrote:
> RepositoryUtil.logout(...) takes in parameter 'String sessionId' , not
> 'String userName'. SessionID is an UUID generated and mapped into
> SessionWrapper.
Ah, you're right. I was mislead by the keying of the session map by
the username. Why not key it directly with the UUID?
> different ) is tested. RepositoryUtil, as such will evolve as I build
> through the application. Currently, each call to login() will return a
> unique SessionWrapper and as per implementation the application can
> either call logout() to release the resources or the resource releasing
> will happen when VM invokes finalize() on the SessionWrapper. I will
> not call the finalize() strategy robust but that is what I have now :-)
OK, Jackrabbit currently doesn't use finalize().
However, aren't there references in RepositoryUtil to all
SessionWrapper instances, preventing them from being garbage
collected? Note that finalize() is by default *not* run when the VM
exits; it's only run before an instance is collected as garbage.
BR,
Jukka Zitting
RE: Posts on JCR and Jackrabbit
Posted by "Boni Gopalan (BioImagene)" <Bo...@bioimagene.com>.
Jukka : thanks for taking time to look through my code.
RepositoryUtil.logout(...) takes in parameter 'String sessionId' , not
'String userName'. SessionID is an UUID generated and mapped into
SessionWrapper. In my testcases (The code is hosted on google code) the
multi session parallel existence and logout (With same user id or
different ) is tested. RepositoryUtil, as such will evolve as I build
through the application. Currently, each call to login() will return a
unique SessionWrapper and as per implementation the application can
either call logout() to release the resources or the resource releasing
will happen when VM invokes finalize() on the SessionWrapper. I will
not call the finalize() strategy robust but that is what I have now :-)
I introduced SessionWrapper exactly to keep and manage different
Sessions per thread (Planning to expand the example to a Blogging app.)
Thanks
Boni
-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
Sent: 24 November 2008 15:58
To: users@jackrabbit.apache.org
Subject: Re: Posts on JCR and Jackrabbit
Hi,
On Mon, Nov 24, 2008 at 9:59 AM, Boni Gopalan (BioImagene)
<Bo...@bioimagene.com> wrote:
> http://whiteboardjunkie.wordpress.com/
>
> I am writing a series of posts on using JCR in enterprise
applications.
Nice!
> I started writing yesterday. As of now most of the posts are
> rudimentary in nature. Please point out mistakes and areas of
> improvement.
I looked at your "Managing JCR Sessions" post and I'm a bit confused
about what you're trying to do.
Why is
SessionWrapper session = RepositoryUtil.login(username, password);
try {
...
} finally {
RepositoryUtil.logout(username);
}
better than
Session session = repository.login(username, password);
try {
...
} finally {
session.logout();
}
?
Also, consider two threads doing the following:
SessionWrapper session = RepositoryUtil.login(username, password);
session.getRootNode();
RepositoryUtil.logout(username);
The following interleaving will break the code:
A: SessionWrapper sessionA = RepositoryUtil.login(username,
password);
B: SessionWrapper sessionB = RepositoryUtil.login(username,
password);
B: sessionB.getRootNode();
B: RepositoryUtil.logout(username);
A: sessionA.getRootNode();
A: RepositoryUtil.logout(username);
This wouldn't be a problem if you used normal Repository.login() and
Session.logout().
BR,
Jukka Zitting
Re: Posts on JCR and Jackrabbit
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Nov 24, 2008 at 9:59 AM, Boni Gopalan (BioImagene)
<Bo...@bioimagene.com> wrote:
> http://whiteboardjunkie.wordpress.com/
>
> I am writing a series of posts on using JCR in enterprise applications.
Nice!
> I started writing yesterday. As of now most of the posts are
> rudimentary in nature. Please point out mistakes and areas of
> improvement.
I looked at your "Managing JCR Sessions" post and I'm a bit confused
about what you're trying to do.
Why is
SessionWrapper session = RepositoryUtil.login(username, password);
try {
...
} finally {
RepositoryUtil.logout(username);
}
better than
Session session = repository.login(username, password);
try {
...
} finally {
session.logout();
}
?
Also, consider two threads doing the following:
SessionWrapper session = RepositoryUtil.login(username, password);
session.getRootNode();
RepositoryUtil.logout(username);
The following interleaving will break the code:
A: SessionWrapper sessionA = RepositoryUtil.login(username, password);
B: SessionWrapper sessionB = RepositoryUtil.login(username, password);
B: sessionB.getRootNode();
B: RepositoryUtil.logout(username);
A: sessionA.getRootNode();
A: RepositoryUtil.logout(username);
This wouldn't be a problem if you used normal Repository.login() and
Session.logout().
BR,
Jukka Zitting