On Wed, 2006-03-01 at 10:18, David M Johnson wrote: > On Mar 1, 2006, at 1:06 PM, Allen Gilliland wrote: > > On Wed, 2006-03-01 at 05:28, David M Johnson wrote: > >>> In the current code I only see this ... > >>> > >>> Roller.begin() - 6 uses > >>> Roller.begin(user) - 4 uses > >>> Roller.commit() - 7 uses > >>> Roller.rollback() - 0 uses > >>> PersistenceStrategy.begin() - 4 uses, just from RollerImpl classes > >>> PersistenceStrategy.commit() - 4 uses, mainly RollerImpl classes > >> > >> Where are you getting that data? Netbeans reports 159 usages of > >> Roller.commit() and 17 usages of Roller.rollback(). > > > > hmm, i am using netbeans as well. > > > > i was using the "Find Usages" function and only counting uses in > > the "src" directory, not tests, etc. it does look like netbeans > > isn't including some usages of "commit" for some reason, i do see > > it appear more times if i do a search. however, i would say that > > uses of begin() and rollback() are the same numbers that i gave > > before, they are obviously not being used everywhere. > > I would expect the numbers for begin() to be small. The pattern is > that we call begin() when we start processing a request, if changes > are made during the request the action that makes them MUST call > commit(), and then when we finish processing a request we call > rollback() just for good measure.
I don't understand that procedure. That sounds like a little bit of a mixup between the concept of a "session" and a "transaction". I am basing this off of the way Hibernate is patterned, but a "session" is often associated with an entire request/response cycle, while a "transaction" represents a single opertion on the data store. So you may have multiple "transactions" in a single "session". I don't think we want to open a transaction at the beginning of the request. A transaction should be open and closed *only* when you are actually accessing the data store and performing an operation. A transaction also should not span more operations that it is supposed to. Each individual load(), store(), or delete() should be its own transaction unless you are doing multiple interdependent operations which must all happen atomically. My understanding is that the begin() method starts a transaction and either commit() or rollback() ends the transaction, we then have release() to close a session that may still be open. So the procedure is ... begin() - opens session if needed, starts transaction ... do your work ... load, store, delete ... if(success) commit() - transaction completed and saved else rollback() - transaction completed and not saved release() - when we no longer need to do any transactions I'm sorry, but this is not the way we are really using these functions. And just to make sure I am properly representing my view point, I am not saying that we don't need to support transactions. I am merely saying that the way things are currently setup I don't believe we are properly using the transaction methods we have and those methods are not actually doing what they suggest. For that reason I believe our current implementation is a little broken. At the same time, and partly based on that observation, I am posing the question of ... do we really need those methods to be called from outside the persistence layer by classes in the presentation layer? Instead, could we not simply leave the transaction logic up to the implementor of the persistence strategy? -- Allen > > - Dave >
