Shane, In this particular application, yes that is exactly what it does. I don't need any modifications that span multiple requests in this particular app.
The client application (ie, the web application) isn't allowed to hold onto "live" domain objects. If need be it can hold onto a transaction with a series of modifications, but then you wind up holding a lot of transactional state around in some type of session (be it a stateful session bean, http session, etc). I have modified domain objects that are not yet persisted all the time - right before they are persisted =) Some of the commands are pretty complex (despite it being a simple application -- it does some fun stuff trying to model human/group relations that has not yet been exposed to the UI) and build quite a bit of domain information before persisting any of it. Right now commands in that particular application are all atomic, however. If I needed to have a long-lived transaction in this application (ie, create and modify a domain object via multiple hits) I would probably design it around capturing the changes in an OTM Transaction and giving the client a transaction token in order to associate the new changes with the previous transaction) -- the domain model is still only "live" within the core application upon which the other apps are just clients with some interface to twiddle it. This type of system doesn't work for everything, but it does for a lot I have found. Large scale GIS systems I am pretty confident it wouldn't work well in, for instance. Does that clear up what I described? -Brian ps: sorry for not quoting, I am at NFJS Atlanta and working through a pita webmail client ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
