On Thu, 2006-03-02 at 17:03, David M Johnson wrote: > On Mar 2, 2006, at 6:53 PM, Allen Gilliland wrote: > > 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. > > I'm definitely for refactoring to move app and persistence logic to > the back end, would like to see some proposals and would love to > help, but we should take somethings into consideration before we > starting making changes. > > It's mostly about timing: > > - We have tagging work from Elias being that we need to get into the > trunk. Probably want to hold off on refactoring until that is > integrated as any changes will make the work harder to integrate. > > - Craig Russell was working on a JDO port of the back-end. > Refactoring will clash with his work to (assuming it is still underway). > > - While refactoring is going on it will be more difficult for others > to work on EJB3 or JDO stuff. For example, now that I'm getting my > free time back (book is done next week) I'm personally interested in > pursuing the EJB3 alternative.
Unfortunately, this is where I will be even more bitchy and say that I am not willing to wait around for everyone else. My personal opinion is that any code that isn't going to be commited within a week or two will just have to be modified to keep up with what's in the trunk. Obviously there are exceptions to this which can be coordinated through the community, but I consider those exceptions and not the default. These are all valid reasons to possibly delay, but ... 1. I have not heard a single thing from Craig Russell on this list and still very little status about a JDO backend. In any case, waiting wouldn't change anything because the JDO classes would still have to be modified at some point. 2. You haven't even started on the EJB3 implementation yet based on what you said. Why not reverse things and you wait a little while until I cleanup the backend so that you have less work to do whenever you do start an EJB3 implementation. 3. The tagging code would likely require little to no changes based on what I am proposing. If anything they would only have to remove some method calls to begin()/commit()/rollback() and possibly tidy up a couple things in any manager classes they created. > > But there are also technical issues: > > - We don't want to do things that will reduce our ability to move to > JDO or EJB3 in the future (e.g. Matt mentioned Spring's declarative > transactions, would that cause problems or redundancy if we moved to > EJB3 at some point?) I don't see that that could happen. I am not proposing that we remove any functionality, I am suggesting that our code be refactored a bit so that some functionality (for persistence transactions) be handled behind the scenes of the persistence layer. > > > Also, what specific thing are you referring to when you say "not > working properly" I am referring to the fact that we are not actively calling begin() before each transaction, and even though we call commit() quite a lot we never call rollback(). This coupled with the fact that we aren't using Hibernate's Transaction functionality leads me to believe that we are not truly using transactions right now. >From what I see in the code it looks like an unfinished thought where much of >the work is there, but it isn't completed to the point of full functionality. -- Allen > > > >>> 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. > > That's what I thought too, but I found though experience that the > most performant approach was to get a connection at the start of a > request and return it to the pool at the end. > > > > 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. > > Yes, that is correct. A session has a one connection. > > > > 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. > > Yes. > > > > 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. > > Yes, I was using transaction in a more general sense, but it is true > that most Roller requests do one database transaction (i.e. issue one > commit() call to make changes to the database). > > > > 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. > > I see what you mean. I wasn't considering a query to be a transaction. > > > >> 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 think we two are in agreement on this. > > - Dave >
