PersistenceManager Patterns for Multithreaded Applications

Question

Hi,
I'm looking for a good way, how to use Kodo JDO in a multithread application
(actually Tomcat ;). The most easy thing is perhaps, to use only one
persistence
manager for the entire application, i.e. for all threads. Another solution
might be,
to create a PersistenceManager for each HTTP request. I don't like the
solution,
to have one PeristenceManager per session, because I expect thousands
concurrent
users. What I'm concerned with is the number of data base connections in
this
case.
So my question to you is, what pattern do you use in your web applications?
When do you create and close the PersistenceManagers to free resources?
Has anybody alreay tried different patterns and compared the performance?
Is there something like a best practice?
Michael

Answer 1

The other nice thing about the filter is that it should be easy to
selectivly store and retrieve the PM in a user's session if they have a
longer running transaction that spans multiple requests.
So far, I've simply been passing the PM to each service method, although I
don't particularliy like that approach. I haven't had time to try anything
different yet and it isn't TOO bad, although I have a few ideas:
1. The hashtable method you mentioned. I see there is a "Registry" pattern
in the "Patterns of Enterprise Application Architecture" book I'm currently
reading, but haven't gotten to it yet. I think it is close to what you
mentioned.
2. Retrieve the PM through JNDI. I don't know, however, if I can set up a
PM in JNDI the way that the CurrentTransaction JNDI lookup works with
container managed transactions.
"Michael" <[email protected]> wrote in message
news:[email protected]...
I've never used a servlet filter before but I must say that is the most
elegant approach I've seen, thanks for sharing that. How do you pass thePM
to the service layer? Do you store it in a hashtable with the current
thread as a key or do you pass it in to each service method?
Thanks,
Michael
"Nathan Voxland" <[email protected]> wrote in message
news:[email protected]...
We've created the PersistenceManager in a filter and attached it to the
request object. That way, the persistence manager can be accessed fromthe
Struts Action, JSP Page, and anything else we do, plus we don't have to
worry about closing it because it is closed by the filter after
everything
is done (Even if an exception is thrown)
Here is the code:
public void doFilter(final ServletRequest request, final ServletResponse
response, FilterChain chain) throws IOException, ServletException {
PersistenceManager pm = getPersistenceManager();
request.setAttribute(JDO_PERSISTENCE_MANAGER, pm);
try {
chain.doFilter(request, response);
} finally {
if (pm.currentTransaction().isActive()) {
pm.currentTransaction().rollback();
pm.close();
"Michael" <[email protected]> wrote in message
news:[email protected]...
I currently doing exactly this: getting a persistence manager at the
beginning of a jsp page and close it at the end of the jsp page.
When you use <jsp:include ...>, you must be careful not to close the
persistence manager to early. I do it like this:
This sounds like a good approach, especially the hashtable with the
thread
as the key. The only issue I see is if you create the PM in the JSPpage,
often an Action is executed before the JSP is called. This is why I
was
thinking of creating the PM in the struts request processor, it'salways
called for every request.