I got tired of, in all my action classes, beginning with something to
get a database connection and at the end destroy it. I want to automate
this a bit.
Here is a first shot at what I came with:
In my subclass of whatever flavor of Action I'm using, a have a
protected variable which holds my Persistence class object. My subclass
implements execute() such that it will instantiate the persistence
object, assign it to the protected class variable and call
super.execute(), getting rid of the connection afterwards. The action
methods themselves just refer to the protected class variable, rather
than doing anything to generate/obtain it itself.
Now, I can only count on this working if, and only if, the Action class
itself got instantiated for the purpose of processing the request, and
destroyed afterward (otherwise the protected variable is going to get
shared between requests). Am I safe here?
If not, I suppose I could make it a ThreadLocal, but then I'd just be
replacing the create/destroy steps with a casting step. And since my
goal here is to try abd have all the work done outside of the "real"
methods, that's kind of self-defeating. Same holds true with using
request.setAttribute() instead. Ideally the persistence layer shouldn't
have to know it's in a web application, so I'd like to not have to pass
in a request object to it at any point.
Am I safe with my first guess? (I suspect not). Failing that, what's a
better idea?
TIA
-Joe
-Basically what I have now is something like this-
protected Persistence persistence;
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws
Exception {
persistence = ActionHelper.getPersistenceObject(request);
ActionForward result = super.execute(mapping, form, request,
response);
persistence.release();
return result;
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
