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 also noticed that in our Hibernate implementation we aren't actually > > using Transactions anyways, so even if these methods were in full > > use we > > wouldn't have been taking advantage of them. > > > > So, the deal is that if we want to use these transaction methods > > then we > > need to make sure we are using them *everywhere*, otherwise they are > > doing us no good and only confusing things. Alternatively I would > > propose that we drop these methods and let implementors of a > > persistence > > strategy handle the details of transactions within their own > > implementations. > > > > My vote is to drop these methods. I can see the potential value in > > having them (if they were working properly), but my opinion is that we > > aren't really doing any persistence transactions complicated enough to > > really warrant the additional complexity and overhead of having them. > > We have to go one way or the other, so we either remove them or add > > them > > in everywhere. > > > > Who else has an opinion? > > I feel pretty strongly that we need to follow that very simple and easy > to follow pattern, keep the transaction methods and make sure they > work properly. There are definitely situations where we want to be > atomic. I agree, we certainly need to maintain proper transactions for some of our writes, but my biggest question is ... can that transaction logic be handled in the persistence layer itself? meaning, can the transaction logic happen behind the scenes of our manager classes? > > Roller was originally developed with a database that didn't support > referential integrity or transactions, but I still tried to do the > right thing > so that, at some point in the future it would be easy to move to a > database > that did support those things. > > I vote that we turn on transaction support in Hibernate and make sure > those begin(), commit() and rollback() methods are working properly. this is the tricky part, because proper transactions also means that you must begin() and commit() or rollback() even when you are only doing a query. basically, every access to the persistence layer should be wrapped inside a transaction, and i don't believe we are doing that right now. i have more comments in response to Anil's email. -- Allen > > - Dave > > > > > > > > -- Allen > > >
