Why not use a separate session (same sessionfactory) for your logging? > -----Original Message----- > From: James Carman [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 13, 2006 6:07 PM > To: 'Tapestry users' > Subject: RE: tapestry-hibernate integration problem > > > I figured out what I was doing wrong. I had my methods on my > squeezer and > custom persistence strategy demarcated wrong. They should > have been marked > as "read-only" since they don't really do anything to change > the state of > the objects. Now that I've turned that off, it seems to be > working fine the > way you describe. However, that does bring up an issue (as I > think you're > alluding to). If I change a persistent object that gets > loaded into the > session and *any* transaction on that session commits, then > those changes > will be persisted. > > So, in my persistence strategy, I reattach an entity to the > current session > (opened up by my open-session-in-view filter). Then, my Form > updates the > entity directly. Then I do my validation and determine that > one of the > properties is invalid. Suppose I want to log a message that says the > current user tried to use an invalid value and that (the saving of the > message) is inside a transaction that commits. Then, the > changes that I > made to the entity, since it was in the session, get persisted to the > database! Yuck. I guess this whole "auto-reattach" stuff > might not work > after all! Any thoughts? > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 13, 2006 8:55 AM > To: 'Tapestry users' > Subject: RE: tapestry-hibernate integration problem > > I'd just call it a feature ;) > > > -----Original Message----- > > From: James Carman [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 13, 2006 1:40 PM > > To: 'Tapestry users' > > Subject: RE: tapestry-hibernate integration problem > > > > > > You're right. I need to fix that. There was not supposed to > > be any active > > transaction while I was updating the properties (using the example > > application). I assumed that since there was no transaction > > present that > > the changes to the objects in the session wouldn't be > > persistent. But, > > maybe there was an active transaction. Hmmmmm. > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 13, 2006 2:20 AM > > To: 'Tapestry users' > > Subject: RE: tapestry-hibernate integration problem > > > > > > > > > -----Original Message----- > > > From: James Carman [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, April 13, 2006 12:42 AM > > > To: 'Tapestry users' > > > Subject: RE: tapestry-hibernate integration problem > > > > > > > > > Anything which really wants to update the persistent objects > > > should go on > > > inside a service method. Then you can put the transaction > > > interceptor on > > > it. > > > > I disagree. When you work directly on your domain model, you > > only have to > > commit. Even in Tapernate, when you persistence strategy > > loads an entity > > from its id, you can just let tapestry change properties and > > commit them. > > What service method do you call in addition? > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
