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.
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.
Actually, you want those two queries to be in one transaction, not two;
otherwise they can see inconsistent state if there is another
transaction committed between the two.
