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)
<Boni.G@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
|