Re: [Wicket-user] Hibernate transactions
it was there really at the beginning. But then developers complained that it was really difficult to have youre own request cyclebecause you needed to first make youre own SessionFactory then youre own Session then youre own RequestCycle factory and then last the RequestCycle itself. that where 4 classes and 5 methods just to do one thing (implement one method)Now in the 1.2 stream it is easier to create a RequestCycle so we could think of moving it.johan On 12/19/05, John Patterson [EMAIL PROTECTED] wrote: On Monday 19 Dec 2005 09:33, Eelco Hillenius wrote: No need for that anymore, it's 'fixed' now (though I don't entirely agree as I stated in another thread).Thanks guys!I have used WebWork previously and this is my first Wicket project.I think it is bloody brilliant.I am really looking forward tozero state support.By the way, I also feel that the RequestCycle would bethe natural place to have such an handle exception listener. John.---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
On Tuesday 20 Dec 2005 04:53, Johan Compagner wrote: it was there really at the beginning. But then developers complained that it was really difficult to have youre own request cycle because you needed to first make youre own SessionFactory then youre own Session then youre own RequestCycle factory and then last the RequestCycle itself. that where 4 classes and 5 methods just to do one thing (implement one method) Sounds like a factory object would help here. It could kind of 'denormalise' the object hierarchy - flatten it out - to make things easier to override while removing the clutter from the Application. That would allow me to easily integrate Picocontainer into the framework by creating a dynamic Proxy. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
Actually, transactions are either committed automaticly within there
method call dao.save(someObject) or if i need to batch several
operations in 1 transaction i let the onclick event commit the
transaction for me.
public void onclick()
{
Object obj=dao.batchLoad(id);
dao.batchDelete(obj);
dao.commit();
}
but thats just how we do things, remember i told you we rollback at
the end of a request. you could just as easilly commit there then you
would not have to worry about mixing transaction code all over wicket
code.
Maurice
2005/12/16, John Patterson [EMAIL PROTECTED]:
It also creates a new transaction for every data operation which does not
allow for making multiple operations atomic.
Not true. Our base dao has methods for batching saves, updates and the
like that use the currently running transaction, with 1 single method
call you can then commit this transaction whenever you want.
So you have transaction related methods on your DAO?
If so the user is responsible for defining the transaction boundary's. I
would prefer this to be automatically handled by the container OR by some
wicket specific handler. Separation of concerns and all that...
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
imho, your transactions should only be concerned with what happens in event handlers (onclick/onsubmit) and not through the enitire request cycle because anything outside the handlers should be read-only access and thus not require a transaction. That would indeed be desirable, however as of the latest hibernate you are required to have atransaction at all times. Even for read only operations. failing to do results in lazyinit exceptions from hibernate. Maurice 2005/12/17, Igor Vaynberg [EMAIL PROTECTED]: yes. considering what you are trying to do that will work. still not sure why you are trying to do it this way, seems silly to me to tie transaction handling with UI code. imho, your transactions should only be concerned with what happens in event handlers (onclick/onsubmit) and not through the enitire request cycle because anything outside the handlers should be read-only access and thus not require a transaction. so i think you are setting the boundaries a bit wide. but as i said, this is imho. anyway i created an example of what you want a while back - pre requestcycle refactoring - so if you want to take a look you can find it here http://www.mail-archive.com/wicket-user@lists.sourceforge.net/msg07587.html my approach was a bit inversed opposed to yours. i used the application to handle sessions and used requestcycle to signal certain events to the application. that way all transaction mgmt lives in the application. -Igor On 12/17/05, John Patterson [EMAIL PROTECTED] wrote: On Saturday 17 Dec 2005 15:19, Igor Vaynberg wrote: you might not be able to do it using the try/catch/finally semantic, but there are plenty of hooks in there to do it without. the iexceptionresponsestrategy is indirectly part of the cycle as well. So the answer is no, you cannot have transaction handling code in one class? This seems like it should be really simple to do so I am not sure I doing it the way you suggest. Is this your suggested approach: 1 - Override WebApplication.getDefaultRequestCycleFactory() to return new instances of my own custom RequestCycle. 2 - Subclass WebRequestCycle to override onEndRequest() where I can commit/rollback the transaction. 3 - Override WebApplication.getDefaultRequestCycleProcessor to create and cache a single instance of CompoundRequestCycleProcessor with my own custom IExceptionResponseStrategy. 4 - Subclass DefaultExceptionResponseProcessor to catch exceptions and signal my custom WebRequestCycle that the transaction should be rolled back in onEndRequest(). Thanks, John --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
On 12/18/05, John Patterson [EMAIL PROTECTED] wrote: On Saturday 17 Dec 2005 23:10, John Patterson wrote: I have checked it out and it looks to me like the method HibernateApplication.onRuntimeException() is never used so transactions will never be rolled back. Despite this missing functionality it is still much more complicated than using a try-catch Sorry, I forgot that this example was built against an older version of wicket. That method would have been called before. It doesn't seem to be called anymore however That's in HEAD again. The method is now called just like before. Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
No need for that anymore, it's 'fixed' now (though I don't entirely agree as I stated in another thread). Eelco On 12/18/05, Igor Vaynberg [EMAIL PROTECTED] wrote: if application.onRuntimeException() is not being called then its a bug. if you verify that it is indeed the case please file a bug. -Igor --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
On Saturday 17 Dec 2005 17:42, Igor Vaynberg wrote: imho, your transactions should only be concerned with what happens in event handlers (onclick/onsubmit) and not through the enitire request cycle Are you suggesting putting transaction handling in each wicket event handler? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
as i said, imho, that is a good place for boundaries because that is the only place where you should be modifying data. any modification outside an event handler should result in an error. at least this is how im used to doing it. -IgorOn 12/17/05, John Patterson [EMAIL PROTECTED] wrote: On Saturday 17 Dec 2005 17:42, Igor Vaynberg wrote: imho, your transactions should only be concerned with what happens in event handlers (onclick/onsubmit) and not through the enitire request cycle Are you suggesting putting transaction handling in each wicket event handler?---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
of course i dont have txn management code in every event handler, i use spring. my service methods are demarkated with their txn attributes and spring handles it all for me transparently via aop. my wicket code knows nothing about transactions or hibernate or any perstence code, it only knows about service interfaces. -IgorOn 12/17/05, Igor Vaynberg [EMAIL PROTECTED] wrote: as i said, imho, that is a good place for boundaries because that is the only place where you should be modifying data. any modification outside an event handler should result in an error. at least this is how im used to doing it. -IgorOn 12/17/05, John Patterson [EMAIL PROTECTED] wrote: On Saturday 17 Dec 2005 17:42, Igor Vaynberg wrote: imho, your transactions should only be concerned with what happens in event handlers (onclick/onsubmit) and not through the enitire request cycle Are you suggesting putting transaction handling in each wicket event handler?---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click___Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
On Saturday 17 Dec 2005 18:31, Igor Vaynberg wrote: of course i dont have txn management code in every event handler, i use spring. my service methods are demarkated with their txn attributes and spring handles it all for me transparently via aop. my wicket code knows nothing about transactions or hibernate or any perstence code, it only knows about service interfaces. Ahh yes this does sound like a better approach. I have never used Spring before. a couple of questions: Can you call multiple operations on your service interfaces in the same transaction? Or is this not done? Can you leave the hibernate session open for the view to be rendered? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
On 12/17/05, John Patterson [EMAIL PROTECTED] wrote:
On Saturday 17 Dec 2005 19:24, Igor Vaynberg wrote: Can you call multiple operations on your service interfaces in the same transaction?Or is this not done? yes. if you mark your service method as PROPOGATION_REQUIRED it will join a
transaction if one exists, or start a new one if one doesnt.I assume the service methods would need to be called by another Spring-managedmethod (service method) - ie not called sequentially from your wicket event
handler - to be included in the same transaction?noep. that is the beautiy of aop and how well transactions fit as an aspect. in the spring context you declare a transactional interceptor for your service ( in case of jdk5 you can simply mark some methods with @Transactional and then spring can do it for you automatically). So when you say
context.getBean(IUserService) you get back an aop-decorated wrapper of your IUserService implementation. It has all the transactional logic in it so you use it as you would a regular service and in background spring handles all the transaction details.
so my onclick handler looks like thisDeleteLink onclick() { User user=userservice.load(userid); . userservice.delete(user); } no mention of transactions anywhere in your code.I also like Pico. it is great for small projects that do not require a lot. I used it back in struts and maverick days. Spring offers everything Pico does, and a ton more that i think every web based project can benefit from.
-Igor
Re: [Wicket-user] Hibernate transactions
AFAIK, this is not how spring PROPOGATION_REQUIRED workingDeleteLink onclick() { User user=userservice.load(userid); userservice.delete(user); User user2=userservice.load
(userid); userservice.delete(user2); } above onClick() will use 4 seperate transactions. i.e. If delete(user2) fail, delete(user) won't be rollback !!
PROPOGATION only ocurrs within out-most service method.On 12/18/05, Igor Vaynberg
[EMAIL PROTECTED] wrote:
On 12/17/05, John Patterson [EMAIL PROTECTED] wrote:
On Saturday 17 Dec 2005 19:24, Igor Vaynberg wrote: Can you call multiple operations on your service interfaces in the same transaction?Or is this not done? yes. if you mark your service method as PROPOGATION_REQUIRED it will join a
transaction if one exists, or start a new one if one doesnt.I assume the service methods would need to be called by another Spring-managedmethod (service method) - ie not called sequentially from your wicket event
handler - to be included in the same transaction?noep. that is the beautiy of aop and how well transactions fit as an aspect. in the spring context you declare a transactional interceptor for your service ( in case of jdk5 you can simply mark some methods with @Transactional and then spring can do it for you automatically). So when you say
context.getBean(IUserService) you get back an aop-decorated wrapper of your IUserService implementation. It has all the transactional logic in it so you use it as you would a regular service and in background spring handles all the transaction details.
so my onclick handler looks like thisDeleteLink onclick() { User user=userservice.load(userid); . userservice.delete(user); } no mention of transactions anywhere in your code.I also like Pico. it is great for small projects that do not require a lot. I used it back in struts and maverick days. Spring offers everything Pico does, and a ton more that i think every web based project can benefit from.
-Igor
-- Ingram ChenJava [EMAIL PROTECTED]Institue of BioMedical Sciences Academia Sinica Taiwanblog: http://www.javaworld.com.tw/roller/page/ingramchen
Re: [Wicket-user] Hibernate transactions
On Saturday 17 Dec 2005 23:10, John Patterson wrote: I have checked it out and it looks to me like the method HibernateApplication.onRuntimeException() is never used so transactions will never be rolled back. Despite this missing functionality it is still much more complicated than using a try-catch Sorry, I forgot that this example was built against an older version of wicket. That method would have been called before. It doesn't seem to be called anymore however - at least 2 more classes are needed. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
yes, sorry i misspoke. every call to the service from outside will have its own transaction, because otherwise how does spring know when the request is over and its time to commit? i always thought that people, at least this was the case with me, used transaction per request because it is the most manageable way to go, not because the semantic of the event handlers really required a single transaction. if it does why arent those operations in their own service method to start with.
-IgorOn 12/17/05, Ingram Chen [EMAIL PROTECTED] wrote:
AFAIK, this is not how spring PROPOGATION_REQUIRED workingDeleteLink onclick() { User user=userservice.load(userid); userservice.delete(user); User user2=
userservice.load
(userid); userservice.delete(user2); } above onClick() will use 4 seperate transactions. i.e. If delete(user2) fail, delete(user) won't be rollback !!
PROPOGATION only ocurrs within out-most service method.On 12/18/05, Igor Vaynberg
[EMAIL PROTECTED] wrote:
On 12/17/05, John Patterson [EMAIL PROTECTED] wrote:
On Saturday 17 Dec 2005 19:24, Igor Vaynberg wrote: Can you call multiple operations on your service interfaces in the same transaction?Or is this not done? yes. if you mark your service method as PROPOGATION_REQUIRED it will join a
transaction if one exists, or start a new one if one doesnt.I assume the service methods would need to be called by another Spring-managedmethod (service method) - ie not called sequentially from your wicket event
handler - to be included in the same transaction?noep. that is the beautiy of aop and how well transactions fit as an aspect. in the spring context you declare a transactional interceptor for your service ( in case of jdk5 you can simply mark some methods with @Transactional and then spring can do it for you automatically). So when you say
context.getBean(IUserService) you get back an aop-decorated wrapper of your IUserService implementation. It has all the transactional logic in it so you use it as you would a regular service and in background spring handles all the transaction details.
so my onclick handler looks like thisDeleteLink onclick() { User user=userservice.load(userid); . userservice.delete(user); } no mention of transactions anywhere in your code.I also like Pico. it is great for small projects that do not require a lot. I used it back in struts and maverick days. Spring offers everything Pico does, and a ton more that i think every web based project can benefit from.
-Igor
-- Ingram ChenJava [EMAIL PROTECTED]Institue of BioMedical Sciences Academia Sinica Taiwanblog:
http://www.javaworld.com.tw/roller/page/ingramchen
Re: [Wicket-user] Hibernate transactions
if application.onRuntimeException() is not being called then its a bug. if you verify that it is indeed the case please file a bug.-IgorOn 12/17/05, John Patterson [EMAIL PROTECTED] wrote: On Saturday 17 Dec 2005 23:10, John Patterson wrote: I have checked it out and it looks to me like the method HibernateApplication.onRuntimeException() is never used so transactions will never be rolled back. Despite this missing functionality it is still much more complicated than using a try-catchSorry, I forgot that this example was built against an older version ofwicket. That method would have been called before. It doesn't seem to becalled anymore however - at least 2 more classes are needed. ---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://ads.osdn.com/?ad_idv37alloc_id865opclick___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
this is indeed a bug. i have a patch ready but i would like to discuss it with the other devs because it causes an api break dude to request cycle refactorings. i will post the patch and the discussion to the devel list. -Igor On 12/17/05, Igor Vaynberg [EMAIL PROTECTED] wrote: if application.onRuntimeException() is not being called then its a bug. if you verify that it is indeed the case please file a bug.-IgorOn 12/17/05, John Patterson [EMAIL PROTECTED] wrote: On Saturday 17 Dec 2005 23:10, John Patterson wrote: I have checked it out and it looks to me like the method HibernateApplication.onRuntimeException() is never used so transactions will never be rolled back. Despite this missing functionality it is still much more complicated than using a try-catchSorry, I forgot that this example was built against an older version ofwicket. That method would have been called before. It doesn't seem to be called anymore however - at least 2 more classes are needed. ---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://ads.osdn.com/?ad_idv37alloc_id865opclick ___ Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
On Friday 16 Dec 2005 05:40, Maurice Marrink wrote: We use the dao pattern. any exceptions are handled by the different dao's. This would require duplicating error and transaction handling in every method. It also creates a new transaction for every data operation which does not allow for making multiple operations atomic. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
On Friday 16 Dec 2005 02:47, Igor Vaynberg wrote:
There is in fact an on error handler Application.onRuntimeException(). its
called whenever there is a runtime exception. instead of trying to do
try/catch in your filter you can use a request variable to indicate
success/failure. set it to success, and in the error handler set it to
failure.
Thanks, this currently looks like the best place to do it but it is very
untidy requiring coordination between more than one object using a request
variable etc.
It also means that I must trust the wicket code to always call
Application.onRuntimeException(). It would be much simpler if I could
override a single method to wrap it in a try-catch-finally block.
for example, if Request cycle had a non-final method:
protected void doRequest() throws RuntimeException
{
// Attach thread local resources for request
threadAttach();
// Response is beginning
internalOnBeginRequest();
onBeginRequest();
// If request is parsed successfully
if (parseRequest())
{
// respond with a page
respond();
}
}
I would then feel much better being able to override this method and wrap it
in my try-catch-finally block. Good and safe.
I use this approach whenever i know my requirements will never
exceed the single-transaction-per-request limitation.
Do you often need more than one transaction per request?
John
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
the full name of the interface is: wicket.request.compound.IExceptionResponseStrategy. you can substitute your own implementation into the compound request cycle processor. if your implementation throws a runtime exception it will get to your filter because there are no try/catch blocks in wicket to catch it at that point. so a patch is not necessary, we already fully support what you want. what would be nice instead is a unit test that makes sure the exception does in fact get through. that way we can make sure we do not break this behaviour with future refactorings. -IgorOn 12/16/05, John Patterson [EMAIL PROTECTED] wrote: On Friday 16 Dec 2005 14:27, Igor Vaynberg wrote: if you really want to you are free to cutomize any piece of request cycle processing you want, in this case take a look at IExceptionResponseStrategy. I can't find this interface... but for the reasons of simplicity and keepingall transaction handling logic in once place it would be much preferable tosimply be able to use a try-catch block around the code. Using this interface would mean that hibernate sessions are commited andclosed in one place and rolled back in another with some kind of ad-hocsignalling between them (eg through a request parameter). Very messy when such a simple alternative is available.Can I supply a patchto be considered?Thanks,John.---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
why not instead of using a filter subclass webrequestcycle and all the transaction logic into it. its all in one place and neat. i think there are ample hooks for the keypoints you need. -Igor On 12/16/05, John Patterson [EMAIL PROTECTED] wrote: On Friday 16 Dec 2005 18:35, Igor Vaynberg wrote: the full name of the interface is: wicket.request.compound.IExceptionResponseStrategy.Cheers.I just did a cvs update and there it was!Wow, a lot has changed. One small thing - the implementation of IExceptionResponseStrategy. is namedDefaultExceptionResponseProcessor.Missed during refactoring? if your implementation throws a runtime exception it will get to your filter because there are no try/catch blocks in wicket to catch it at that point.The problem is that when an exception is thrown I want to rollback mytransaction AND then use wickets handy exception handling behaviour. we already fully support what you want.If I simply throw the exception then I have skipped the redirect to the errorpage etc.So again I am in the same situation as before.I want to be able to have transaction handling code in one place - not in several objects that interactby setting request variables etc.Can you suggest a way to do this?The only way I could see to do it is if RequestCycle.steps () was refactored tothrow any Exceptions with exception handling code (ieIExceptionResponseStrategy.respond) in the calling method.Then I could simply override this method to all intercept exceptions, commit or rolllback transaction, and call super.steps() (or doSteps()) to resumewickets normal error handling.John---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Hibernate transactions
There is in fact an on error handler Application.onRuntimeException().
its called whenever there is a runtime exception. instead of trying to
do try/catch in your filter you can use a request variable to indicate
success/failure. set it to success, and in the error handler set it to
failure. I use this approach whenever i know my requirements will never
exceed the single-transaction-per-request limitation.
Hope this helps,
-Igor
On 12/15/05, John Patterson [EMAIL PROTECTED] wrote:
Hi,I am using hibernate with my wicket application and was wondering how I cancontrol transactions?Usually I use a servlet filter that either commits thecurrent transaction or rolls it back.Something like this:
try{ chain.doFilter(req, resp);// commit if needed}catch (Exception e){// roll back if needed}finally{// close session if needed}I am using wicket HEAD and all exceptions are caught and handled in the
RequestCycle so my catch block is never called.Instead of using a servletfilter I tried subclassing WebRequestCycle to use onBeginRequest andonEndRequest.But how do I catch exceptions to rollback the current
transaction?I was looking for some kind of onError handler.How do others handle this?Thanks,John---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
