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:[EMAIL PROTECTED] Sent: 24 November 2008 16:36 To: [email protected] Subject: Re: Posts on JCR and Jackrabbit Hi, On Mon, Nov 24, 2008 at 11:47 AM, Boni Gopalan (BioImagene) <[EMAIL PROTECTED]> 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
