Re: Hibernate Transactions and Wicket
Mark your transactional method that does validation as readOnly=true On Fri, Jun 19, 2009 at 2:02 PM, Ryan wrote: > Consider this use case: > > 1) User object is read from hibernate, either in a transaction or not > 2) User is modified via wicket, and passed wicket's validation > 3) User is sent to service tier for further validation, this service is > marked as propagation required > 4) Validation fails, or for some reason the user should not be > persisted. At this point a number of things can happen: > > a. Throw exception, which clears the hibernate session and rolls back > b. manually call session.clear on the hibernate session > c. Let the method finish, perhaps returning false. This will auto > commit the transaction and the user is persisted. > > It gets even more tricky if Wicket also read another entity from > hibernate and modified it, but it was not ready to be persisted to the > db. When the transactional service method is called on the user object, > it will commit and flush *any* modified objects loaded in the hibernate > session. > > My setup adds another option to the list. Since all the transactions > are readonly, the service tier must call a specific dao method that is > marked as read-write and requires_new. This creates a new hibernate > session which merges *only* the object passed into the method. > > It all comes down to handling detached objects or long hibernate > sessions. It is by no means a new issue, but I think it can confuse > first time users of LDMs. > > -Ryan > > On Fri, Jun 19, 2009 at 06:30:14AM -0400, James Carman exclaimed: > >>The only changes that will be persisted to the database are ones that >>go on within a transaction. So, do all of your work in transactional >>methods (in spring-managed beans), but leave your session open for the >>entire request so that you can traverse relationships if necessary. >> >>On Fri, Jun 19, 2009 at 1:43 AM, Ryan wrote: >>> >>> I have been reading Nick Wiedenbrueck's blog, specifically about >>> patterns and pitfalls when using wicket with spring and hibernate. >>> >>> It seems fairly common for programmers to run into the "issue" of having >>> entities persisted to the database at unexpected times. This happens >>> when a transaction is closed and the hibernate session is flushed. >>> Certainly this issue is not specific to using Wicket with spring and >>> hibernate, but I think it is common enough to warrant some attention. >>> >>> There are a few suggestions to solving this problem: >>> >>> 1) Use DTOs >>> 2) Make sure validation happens in wicket so the object is not modified >>> 3) Clear the hibernate session or throw exceptions at just the right >>> times >>> >>> I think all of these have some issues. Using DTOs is code heavy. >>> Validating entirely in wicket is not always an option (sometimes the >>> service tier needs to do some extended business validation). Clearing >>> the hibernate session or throwing exceptions will cause Lazy >>> Initialization exceptions if not used carefully (which can be hard when >>> you do not control all the components on a page) >>> >>> I wanted to share one solution I have used and see what others think. >>> >>> I mark all of my transactional methods (usually in the service) as read >>> only. I then define a set of "persist" methods (usually on a DAO) that >>> are marked as REQUIRES_NEW and are not read only. When I am ready to >>> persist an object it is passed to one of these methods and merged into >>> the session. This effectively persists the object. Some of these persist >>> methods can take a collection of objects so that they can be persisted >>> efficiently in one transaction. So far this has worked well for me. >>> >>> Does anyone have any thoughts on this method or can share some other >>> techniques? >>> >>> Thanks, >>> Ryan >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >> >>- >>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>For additional commands, e-mail: users-h...@wicket.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hibernate Transactions and Wicket
Consider this use case: 1) User object is read from hibernate, either in a transaction or not 2) User is modified via wicket, and passed wicket's validation 3) User is sent to service tier for further validation, this service is marked as propagation required 4) Validation fails, or for some reason the user should not be persisted. At this point a number of things can happen: a. Throw exception, which clears the hibernate session and rolls back b. manually call session.clear on the hibernate session c. Let the method finish, perhaps returning false. This will auto commit the transaction and the user is persisted. It gets even more tricky if Wicket also read another entity from hibernate and modified it, but it was not ready to be persisted to the db. When the transactional service method is called on the user object, it will commit and flush *any* modified objects loaded in the hibernate session. My setup adds another option to the list. Since all the transactions are readonly, the service tier must call a specific dao method that is marked as read-write and requires_new. This creates a new hibernate session which merges *only* the object passed into the method. It all comes down to handling detached objects or long hibernate sessions. It is by no means a new issue, but I think it can confuse first time users of LDMs. -Ryan On Fri, Jun 19, 2009 at 06:30:14AM -0400, James Carman exclaimed: >The only changes that will be persisted to the database are ones that >go on within a transaction. So, do all of your work in transactional >methods (in spring-managed beans), but leave your session open for the >entire request so that you can traverse relationships if necessary. > >On Fri, Jun 19, 2009 at 1:43 AM, Ryan wrote: >> >> I have been reading Nick Wiedenbrueck's blog, specifically about >> patterns and pitfalls when using wicket with spring and hibernate. >> >> It seems fairly common for programmers to run into the "issue" of having >> entities persisted to the database at unexpected times. This happens >> when a transaction is closed and the hibernate session is flushed. >> Certainly this issue is not specific to using Wicket with spring and >> hibernate, but I think it is common enough to warrant some attention. >> >> There are a few suggestions to solving this problem: >> >> 1) Use DTOs >> 2) Make sure validation happens in wicket so the object is not modified >> 3) Clear the hibernate session or throw exceptions at just the right >> times >> >> I think all of these have some issues. Using DTOs is code heavy. >> Validating entirely in wicket is not always an option (sometimes the >> service tier needs to do some extended business validation). Clearing >> the hibernate session or throwing exceptions will cause Lazy >> Initialization exceptions if not used carefully (which can be hard when >> you do not control all the components on a page) >> >> I wanted to share one solution I have used and see what others think. >> >> I mark all of my transactional methods (usually in the service) as read >> only. I then define a set of "persist" methods (usually on a DAO) that >> are marked as REQUIRES_NEW and are not read only. When I am ready to >> persist an object it is passed to one of these methods and merged into >> the session. This effectively persists the object. Some of these persist >> methods can take a collection of objects so that they can be persisted >> efficiently in one transaction. So far this has worked well for me. >> >> Does anyone have any thoughts on this method or can share some other >> techniques? >> >> Thanks, >> Ryan >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > >- >To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hibernate Transactions and Wicket
I use Entity objects directly as well. I read the thread you mentioned and it sounds like you do not use Spring. In our application we are using spring and so the solutions are a bit different. I just wanted to offer up another solution to the problem when using Spring to manage transactions and the hibernate session. On Fri, Jun 19, 2009 at 10:42:16AM +0300, Martin Makundi exclaimed: >> 1) Use DTOs >> I think all of these have some issues. Using DTOs is code heavy. > >I use @Entity objects directly as objects. No overhead. > >There was some discussion about Hibernate and wicket in: >* http://www.nabble.com/JPA-EntityManager-storage-td23888325.html >* http://www.mail-archive.com/users@wicket.apache.org/msg37772.html > >** >Martin > >- >To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hibernate Transactions and Wicket
I think your misunderstanding the issue. My application is working fine, no lazy init issues etc. I call merge because I *want* things persisted to the DB. I mentioned the lazy init exception because that is what happens if you clear the hibernate session (and spring will do it if it rolls back a transaction). Here is the blog post with a concrete example: http://stronglytypedblog.blogspot.com/2009/03/wicket-patterns-and-pitfalls-3.html I only sent the email as another option for the Session flushing that happens when a transaction (or nested transaction) is committed. -Ryan On Fri, Jun 19, 2009 at 11:45:42AM +0530, vineet semwal exclaimed: >lazy initialization exception happens whens you try to initialize a object >(generally collection) >and hibernate session is already closed. >merge is not recommended ,it attaches a object back to hibernate session + >also cause database update( why will you update a object when you actually >need to read a collection also what are the chances that it won't give you >the same lazy initialized exception again as hibernate session can be closed >before you try to access the collection.) > >Simple solutions >1) eager fetch the collection if it's small. >2)For a big collection, write a method in data access layer that retrieves >collection/association( initialize the collection this time). > you can also do database paging in this case. > >regards, >vineet semwal > >On Fri, Jun 19, 2009 at 11:13 AM, Ryan wrote: > >> I have been reading Nick Wiedenbrueck's blog, specifically about >> patterns and pitfalls when using wicket with spring and hibernate. >> >> It seems fairly common for programmers to run into the "issue" of having >> entities persisted to the database at unexpected times. This happens >> when a transaction is closed and the hibernate session is flushed. >> Certainly this issue is not specific to using Wicket with spring and >> hibernate, but I think it is common enough to warrant some attention. >> >> There are a few suggestions to solving this problem: >> >> 1) Use DTOs >> 2) Make sure validation happens in wicket so the object is not modified >> 3) Clear the hibernate session or throw exceptions at just the right >> times >> >> I think all of these have some issues. Using DTOs is code heavy. >> Validating entirely in wicket is not always an option (sometimes the >> service tier needs to do some extended business validation). Clearing >> the hibernate session or throwing exceptions will cause Lazy >> Initialization exceptions if not used carefully (which can be hard when >> you do not control all the components on a page) >> >> I wanted to share one solution I have used and see what others think. >> >> I mark all of my transactional methods (usually in the service) as read >> only. I then define a set of "persist" methods (usually on a DAO) that >> are marked as REQUIRES_NEW and are not read only. When I am ready to >> persist an object it is passed to one of these methods and merged into >> the session. This effectively persists the object. Some of these persist >> methods can take a collection of objects so that they can be persisted >> efficiently in one transaction. So far this has worked well for me. >> >> Does anyone have any thoughts on this method or can share some other >> techniques? >> >> Thanks, >> Ryan >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hibernate Transactions and Wicket
The only changes that will be persisted to the database are ones that go on within a transaction. So, do all of your work in transactional methods (in spring-managed beans), but leave your session open for the entire request so that you can traverse relationships if necessary. On Fri, Jun 19, 2009 at 1:43 AM, Ryan wrote: > > I have been reading Nick Wiedenbrueck's blog, specifically about > patterns and pitfalls when using wicket with spring and hibernate. > > It seems fairly common for programmers to run into the "issue" of having > entities persisted to the database at unexpected times. This happens > when a transaction is closed and the hibernate session is flushed. > Certainly this issue is not specific to using Wicket with spring and > hibernate, but I think it is common enough to warrant some attention. > > There are a few suggestions to solving this problem: > > 1) Use DTOs > 2) Make sure validation happens in wicket so the object is not modified > 3) Clear the hibernate session or throw exceptions at just the right > times > > I think all of these have some issues. Using DTOs is code heavy. > Validating entirely in wicket is not always an option (sometimes the > service tier needs to do some extended business validation). Clearing > the hibernate session or throwing exceptions will cause Lazy > Initialization exceptions if not used carefully (which can be hard when > you do not control all the components on a page) > > I wanted to share one solution I have used and see what others think. > > I mark all of my transactional methods (usually in the service) as read > only. I then define a set of "persist" methods (usually on a DAO) that > are marked as REQUIRES_NEW and are not read only. When I am ready to > persist an object it is passed to one of these methods and merged into > the session. This effectively persists the object. Some of these persist > methods can take a collection of objects so that they can be persisted > efficiently in one transaction. So far this has worked well for me. > > Does anyone have any thoughts on this method or can share some other > techniques? > > Thanks, > Ryan > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hibernate Transactions and Wicket
> 1) Use DTOs > I think all of these have some issues. Using DTOs is code heavy. I use @Entity objects directly as objects. No overhead. There was some discussion about Hibernate and wicket in: * http://www.nabble.com/JPA-EntityManager-storage-td23888325.html * http://www.mail-archive.com/users@wicket.apache.org/msg37772.html ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hibernate Transactions and Wicket
lazy initialization exception happens whens you try to initialize a object (generally collection) and hibernate session is already closed. merge is not recommended ,it attaches a object back to hibernate session + also cause database update( why will you update a object when you actually need to read a collection also what are the chances that it won't give you the same lazy initialized exception again as hibernate session can be closed before you try to access the collection.) Simple solutions 1) eager fetch the collection if it's small. 2)For a big collection, write a method in data access layer that retrieves collection/association( initialize the collection this time). you can also do database paging in this case. regards, vineet semwal On Fri, Jun 19, 2009 at 11:13 AM, Ryan wrote: > I have been reading Nick Wiedenbrueck's blog, specifically about > patterns and pitfalls when using wicket with spring and hibernate. > > It seems fairly common for programmers to run into the "issue" of having > entities persisted to the database at unexpected times. This happens > when a transaction is closed and the hibernate session is flushed. > Certainly this issue is not specific to using Wicket with spring and > hibernate, but I think it is common enough to warrant some attention. > > There are a few suggestions to solving this problem: > > 1) Use DTOs > 2) Make sure validation happens in wicket so the object is not modified > 3) Clear the hibernate session or throw exceptions at just the right > times > > I think all of these have some issues. Using DTOs is code heavy. > Validating entirely in wicket is not always an option (sometimes the > service tier needs to do some extended business validation). Clearing > the hibernate session or throwing exceptions will cause Lazy > Initialization exceptions if not used carefully (which can be hard when > you do not control all the components on a page) > > I wanted to share one solution I have used and see what others think. > > I mark all of my transactional methods (usually in the service) as read > only. I then define a set of "persist" methods (usually on a DAO) that > are marked as REQUIRES_NEW and are not read only. When I am ready to > persist an object it is passed to one of these methods and merged into > the session. This effectively persists the object. Some of these persist > methods can take a collection of objects so that they can be persisted > efficiently in one transaction. So far this has worked well for me. > > Does anyone have any thoughts on this method or can share some other > techniques? > > Thanks, > Ryan > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Hibernate Transactions and Wicket
I have been reading Nick Wiedenbrueck's blog, specifically about patterns and pitfalls when using wicket with spring and hibernate. It seems fairly common for programmers to run into the "issue" of having entities persisted to the database at unexpected times. This happens when a transaction is closed and the hibernate session is flushed. Certainly this issue is not specific to using Wicket with spring and hibernate, but I think it is common enough to warrant some attention. There are a few suggestions to solving this problem: 1) Use DTOs 2) Make sure validation happens in wicket so the object is not modified 3) Clear the hibernate session or throw exceptions at just the right times I think all of these have some issues. Using DTOs is code heavy. Validating entirely in wicket is not always an option (sometimes the service tier needs to do some extended business validation). Clearing the hibernate session or throwing exceptions will cause Lazy Initialization exceptions if not used carefully (which can be hard when you do not control all the components on a page) I wanted to share one solution I have used and see what others think. I mark all of my transactional methods (usually in the service) as read only. I then define a set of "persist" methods (usually on a DAO) that are marked as REQUIRES_NEW and are not read only. When I am ready to persist an object it is passed to one of these methods and merged into the session. This effectively persists the object. Some of these persist methods can take a collection of objects so that they can be persisted efficiently in one transaction. So far this has worked well for me. Does anyone have any thoughts on this method or can share some other techniques? Thanks, Ryan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
