On Thu, 2006-03-02 at 14:31, David M Johnson wrote: > On Mar 2, 2006, at 1:55 PM, Allen Gilliland wrote: > > On Wed, 2006-03-01 at 22:00, Anil Gangolli wrote: > >> OK. -1. I'm against dropping them until we understand the > >> pattern that > >> is being proposed to replace them. > > The pattern would be to encapsulate things in logical operations in > > the manager classes. When you do things like weblog.delete() or > > user.delete() or register a weblog, those things are multi step > > operations to the persistence layer, but they are a single > > operation logically. > > That's a good goal to have, but we're not there yet and it will take > significant refactoring to get there. I totally agree that there is > too much app logic in the presentation layer. That stuff should be > moved into the manager classes behind the Roller interface.
I'm sorry if this sounds like badgering, but "we're not there yet" because nobody has stepped up and 1) identified the problem and 2) said they will do the work. I am saying right now that I will do that work because I think it's an extremely important and fundamental aspect of the application which I believe is currently not working properly. > > > >> Ideally there should be very few places in the app where explicit > >> transaction demarcation is needed. If we really have that many > >> calls, > >> it probably is a sign that it isn't being done right. Typically the > >> demarcation should be very early on request stacks in generic places > >> (filters, async task execution, etc.). > > > > This part I disagree with. My opinion is that each time a db > > connection is opened and closed that represents a "transaction" > > with the database. > > That's not true. You can open a connection at the start of a request, > do several transactions, and then close the connection. > > > > We may open and close our db connection many times in a given > > request/response cycle in order to fetch data and/or save it. > > That's not a good idea. The design has always been to use *at most* > one database connection in the processing a request. If that's not > happening, then we have a bug. I think we are mixing concepts again. First off, unless someone is not using a connection pool then technically their database connection is always open. A normal connection pool keeps all of its connections to the database open at all times. Secondly, a transaction is more like opening a Statement for execution, not opening an entirely new database connection. I am not positive, but I believe Hibernate ensures that only a single database connection is associated with a Session until the Session is closed. So we are agreeing on the same pattern, you open a Session once per request and during that Session you perform any number of Transactions. > > > > You can't just lump the entire request/response cycle into a single > > transaction. > > In most cases, at least in Roller, a request is exactly one transaction. again, I think we are crossing our vocabulary. I think of a transaction as being a single atomic unit of work done against the database. You may do multiple sql operations in a single transaction, but the transaction as a whole represents one unit of work. An entire request does not have to be a single transaction in my mind. Consider. In a single request you may start by querying for a dozen objects which you will use along the way, perhaps the UserData for the user who is logged in, etc. Then the request hits the proper struts action class where it collects data from the request object, formats it, and uses it to store a new weblog entry. Then you continue on to the view where you find you need to query for a few more objects used to populate the display. In my mind that single request included multiple transactions. > > > >> Regarding existing transaction behavior, there are a couple of > >> things to > >> keep in mind: (a) generally there is an implicit transaction > >> associated > >> with all work on the JDBC connection between commits, (b) Roller code > >> may in places be relying on automatic rollback on return to the pool, > >> which strictly speaking it shouldn't. > > > > a. fine, but that transaction logic should be hidden from the > > application and masked by our persistence layer classes. the whole > > point of architecting the persistence layer interfaces is to keep > > persistence specific logic out of the rest of the code. > > Maybe so, but until we've refactored all app and persistence logic > into the back-end managers, we need begin(), commit() and rollback(). Ok, then how about I go ahead and do that? > > And even after we've done that, we may still need Open Session in View: > http://www.hibernate.org/43.html There is nothing that prevents us from doing this. > > > >> I don't think we need to refer to Hibernate Transactions explicitly. > >> That doesn't mean we don't use transactions now. > > > > well, i think that our Hibernate persistence implementation should > > use Hibernate Transactions explicitly. > > Yeah, that's what the Hibernate docs recommend. It does add a > dependency on the JTA jars though. I would have to look into it further, but I don't think you have to use JTA. Hibernate's built-in Transaction support is meant to allow for plugging in various transaction strategies, like JTA. -- Allen > > > > I still claim that our current code does not support transactions. > > Have you turned auto-commit off and tried to verify that? > > - Dave >
