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.
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.
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.
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().
And even after we've done that, we may still need Open Session in View:
http://www.hibernate.org/43.html
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 still claim that our current code does not support transactions.
Have you turned auto-commit off and tried to verify that?
- Dave
