On Nov 20, 2007 12:11 AM, Ezra Epstein <[EMAIL PROTECTED]> wrote: > I imagine that if you use Spring's declarative transactions on the service > layer so that the read()/get() method does not start a read/write transaction > but the save() method does then changing the object without calling "save()" > should just work - you won't be in a read/write tx and so the changes to the > object won't be persisted. I haven't tested this.
Thanks for that Ezra. I'd like to see if we can do this without resorting to spring (hence my interest in Thiago's HiberTapestry), but the pattern is probably transferable. Its similiar to Jonathan's earlier suggestion, yes? One caveat with this approach, as i understand it, is it relies on additional configuration and programmer discipline for the most common case: @Transactional(readOnly=true) Entity findEntity() ... @Transactional() void unitOfWork(Entity entity) So if i - the careless, harried programmer - forget either to add the annotation on the finder or to set the readOnly flag, i'm susceptible. Whats more the consequences of this may not be immediately noticeable since we could easily not be testing for this odd case[1] and the save could easily go through without error. Anyway, it appears i have some work to do! Cheers, lasitha. [1] I'd probably test that validation kicks in and my mock dao isn't called upon to save, but not that hibernate's flush didn't inadvertently save. Even if i did test this in an integration test, i'd have to do this for every occurrence! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
