Hi, Thanks for taking the time to respond, this is really helpful information.
Norman Franke wrote: > My application only uses detached objects that it persists in the > client page for change detection (to determine if the record they > were editing changed while they were editing, which I flag as an > error.) Otherwise, I just re-query as needed for each page. Yeah, I've been considering something similar. My alternative to trying to reattach a detached object would be to "squeeze" my persistent object into three bits of info: the persistent class, the ID of the instance, and the version number. I'm using Hibernate's support for versioning, so the version number would be enough to tell me if a conflicting update was made. This approach would be enough for most purposes, but until I read your message here I wasn't really sure how I was going to handle persisting not-yet-committed changes across multiple pages (say, a multi-step form or wizard) without using a detached object. > To persist a detached object, I call a clone() function on all of my > DB objects that converts it back to a normal POJO (from whatever > Hibernate does to it.) That's a good idea, and I might end up doing the same thing. The only thing I don't like about it is the overhead of implementing the clone() for each persistent object, but I could learn to live with that. > This approach uses no locks or mutexes. That's definitely an advantage, especially to me, because I don't yet trust myself enough to write too much code that uses locks and be confident that I've done it properly and in a way that can scale... Thanks again for the response. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
