If you don't want to go Spring or you're not allowed to (some middle
management still doesn't get it :-)) ) you do what they do :-D w/o using
the whole Spring framework. To extract the transaction and exception
logic from the code you might want to use callbacks. What I mean by that:
define a TransactionCallback interface with one method:
public interface TransactionCallback {
public Object transactionalOperation(Session session) throws
HibernateException;
}
Than you build a template for running transcations, template that will
handle transaction demarcation and exception handling:
public class Template {
public Object execute(TransactionalCallback callback){
try {
//open session if necessary, use the threadLocal pattern
//begin tx
callback.transactionalOperation(openedSession)
//end tx
// close session if necessary
} catch (Hib exception) {
// handle hibernate exception
}
}
}
Than in the application code you go:
Template template = new Template();
// get an object
Serializable id ... ;
User user = (User) template.execute(new TranssactionalCallback(){
public Object transactionalOperation(Session session) throws
HibernateException {
return session.get(User.class, id);
}
});
}
Please note that this is not complete code, you have to work more on it
to make it production ready, I was just ilustrating the ideea. Spring
support doesn't resume to this, they offer a lot more but if you just
want to get TX/exception out of your business code you might consider
the example above. To get the complete picture please take a look into
the Spring code, or read Rod Jonhson's J2EE w/o EJBs to see a better
description of this aproach. Also if you use Spring with Hibernate take
a look at Hibernate3 and spring 1.2.X because some things are pretty
different, I hear.
Good luck :-D
Igor Vaynberg wrote:
We already discussed that. If you want to separate transaction management
from wicket use a dao/service layer that lives inside spring and lets spring
handle transaction management. That way you have declarative transaction
management with retries and all that good stuff. Check out wicket-phonebook
from wicket-stuff for a good starting point. If you are using jdk5 there are
features that significantly shorten and simplify the spring configuration
file.
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gili
Sent: Thursday, October 20, 2005 9:58 AM
To: [email protected]
Subject: Re: [Wicket-user] Wicket, Hibernate and
StaleObjectStateException
Fair enough, I have something similar going right now.
But this still leaves one problem:
If StaleObjectStateException is thrown inside
Form.onSubmit() I am forced to handle it (and retry) inside
onSubmit() as opposed to
(ideally) handling it outside Wicket and retrying the entire
HTTP request. Right now I have a whole bunch of transaction
blocks defined
*inside* my application code which is a disaster. It kills
readability as well as making my application aware of
transactions when ideally it shouldn't have to care about it.
In http://www.hibernate.org/42.html they write: "Our
goal really is to remove any transaction demarcation code
from the data access code" which is exactly what I'm trying
to accomplish...
Gili
Igor Vaynberg wrote:
Instead of doing this:
Onbeginrequest() { mysession=factory.opensession();
mysession.begintransaction(); }
Session getSession() { return mysession; }
Do this:
Onbeginrequest() { mysession=null; }
Session getSession() { if (mysession==null) {
mysession=factory.opensession(); mysession.begintransaction(); }
return mysession; }
Then when an error occurs just reset mysession back to null
and next
time you need one you will get a fresh one
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gili
Sent: Wednesday, October 19, 2005 11:44 PM
To: [EMAIL PROTECTED]
Subject: [Wicket-user] Wicket, Hibernate and
StaleObjectStateException
Hi,
I'm trying to figure out how to handle
StaleObjectStateException in
the context of Wicket. Using the current-state pattern as reference
(http://www.hibernate.org/42.html) if a
StaleObjectStateException is
thrown, I'd like to rollback the transaction, close the
session, open
a new session and transaction and retry the operation.
Ideally I want
to keep this logic completely out of the Wicket code. I
simply don't
see how this can be done.
For example, say I have a page containing a Form and
Form.onSubmit() is invoked and in its body
StaleObjectStateException
is thrown. Following the "Session per HTTP request"
pattern, we're in
a new HTTP request (I
think) but I don't think Wicket will invoke beginRequest() and
endRequest() before and after Form.onSubmit(). Even if it did, I'd
have no way to signal to Wicket to retry the
onSubmit() operation by catching the exception outside it.
So on the one hand, I don't want to catch the
exceptions inside the
Wicket code. On the other hand, I can't retry the operation
if I catch
the exception outside the Wicket code.
Your advice would be appreciated.
Thank you,
Gili
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
__________ NOD32 1.1187 (20050805) Information __________
This message was checked by NOD32 Antivirus System.
http://www.nod32.com
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
