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.
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?)
Also, what specific thing are you referring to when you say "not
working properly"
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
