On Wed, 2006-03-01 at 08:55, Anil Gangolli wrote: > We definitely need transactions with our coding pattern. We will get > inconsistent data states without them if the server goes down or a > request hits an exception after partially updating.
That's fine, we can have transactions, but does the transaction logic need to be controlled from outside of our persistence layer? I would expect that calling WeblogManager.createWeblog() would perform a number of writes which are wrapped in a transaction, but the caller of that method doesn't need to know about that. All it needs to know is if the operation as a whole was successful. I will admit that I haven't yet taken the time to truly analyze all the places in which we are doing persistence operations that require full transaction support, but even without that info I am asking the basic question of whether or not we need to expose persistence specific methods like begin(), commit(), and rollback() into presentation layer code. In my perfect world the details of how a persitence operation is handled is black boxed from the point of view of the presentation code. > > We are using transactions, or were as of about 1.2. I'm not sure why > you say we aren't using them. I fixed some bugs related to this in 1.0 > or so. It does require that your db and db configuration support > transactions. well, I am looking at our Hibernate implementation and we never use the Transaction class of hibernate, so that is one indication. another indication is that we aren't using the Roller.rollback() function, so whatever transactions we are trying to do we aren't rolling them back if they fail. > > Only a few calls are necessary, so the number of calls is not an > indication of lack of use; the transaction demarcation calls should be > early in the entry points of requests into the system or in tasks > executed asynchronously in their own threads. These are supposed to > associate a transaction with the thread. Everything else gets the > current transaction on the thread. It's a standard pattern. well, a few calls multiplied times the number of places where the transaction needs to be started and commited/rolled back. i consider all communication with the persistence layer to be a "transaction". Please note that I am not suggesting that we abandon the use of any transaction support. I am only trying to question whether we need to expose persistence transaction methods outside of our actual persistence layer. I fully agree that behind the scenes of the persistence layer transactions should be supported. -- Allen > > --a. > > > > > Allen Gilliland wrote: > > I have been going through some of the Roller backend and looking at some > > parts of our Hibernate implementation and I have gotten myself to > > wondering if we really need the transaction methods begin() and commit() > > which are part of the Roller and PersistenceStrategy interfaces. > > > > I think I understand where the idea for these methods came from and they > > make some sense, but after inspecting the code a bit it seems like we > > definitely don't actually use them. > > > > 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 > > > > 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? > > > > -- Allen > > > > > > > > >
