I guess I'm also not understanding the need to introduce an
"intent-to-update".
I'm not against introducing a Roller.begin() again if it is needed, but I'd
just prefer to do this so that calls to it are localized, either as Allen
does now (implicit lazily in the persistence layer) or in a filter uniformly
(implicit ahead of time, and always). I don't see the need for explicit
calls sprinkled over the code. Can we get more elaboration here?
In our apps (since we're not doing distributed / XA transactions) isn't a
begin() really just going to grab a JDBC connection out of the pool and
associate it with the thread and transaction management layer? Won't the
connections always have an implicit transaction in effect on them? What's
different about the JDO case here? What am I missing?
Regarding the cost of the begin(), I also don't see a huge one unless the
pool is configured to check the connection on checkouts, there is generally
no cost to get a connection from the pool. I think there is a small cost to
return an item to the pool because the pool will typically do (at least I
believe DBCP does) a rollback for safety on the connection to avoid
"crosstalk" with the next caller if the returning caller forgot to commit or
rollback.
--a.
----- Original Message -----
From: "Allen Gilliland" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, June 29, 2006 10:46 AM
Subject: Re: Add "notify intent to update" method to Roller
I still think this is a step backwards. A major goal for the persistence
implementation is transparency and having to explicitly mark every time you
want to start working on an object seems like a step in the wrong direction
to me.
more comments inline ...
Dave Johnson wrote:
Craig and I spent some time talking about this issue here at
ApacheCon. Apparently, this is a performance/efficiency issue.
Transactions are expensive and you don't want to start one if you are
not going to be making changes. If you're doing read-only access to
data, then the O/R mapping framework does not need to keep copies of
original objects so that it can do change-diffs at commit time.
does Hibernate do the same thing? how big of a performance hit are we
talking about? I don't think the memory part is really an issue, we are
talking about a small set of objects which would only take up memory for
the amount of time it takes to handle the request.
Hibernate must already be doing all of this and it doesn't seem to cause a
problem, so I'm not sure what the big deal is.
Currently in Roller, we do an update on every request due to the
referrer/hit counting but at some point we'd like to be able to take
referrer/tracking off-line (e.g. do it via cron-driven log analysis)
and we'll be able to benefit from increased performance/decreased
memory usage that read-only access can give us.
So why not require a roller.begin() call before changes are made? It's
not exactly a burden on those developing Struts actions or on the
code in the business-layer. Begin, commit and rollback is a well known
pattern and it's well known for a reason.
maybe, but our current pattern seems to be working well and offers much
greater transparency than this approach.
if we decide that we really do need to add a begin() method then so be it,
but i would still lobby against exposing the rollback() method. there is
no reason to do that. a failed commit() should always include a
rollback(), so there is no need to push that logic outside of the
persistence layer.
-- Allen
- Dave
On 6/8/06, Anil Gangolli <[EMAIL PROTECTED]> wrote:
I agree with Allen.
I suspect that what's confusing Craig is the same thing that confused me
initially. There is an unconventional asymmetry in our current pattern.
The Roller interface exposes flush() but not the equivalent of begin(),
which still (always) happens but is not exposed.
Still the current pattern seems workable for JDO too. To implement the
current pattern for JDO one would create a JDOPersistenceStrategy class
that
ensures that a transaction is in progress and sets up any necessary pojo
context (does the equivalent of
HibernatePersistencyStrategy.getSession()
for JDO), and to call this method from the JDO manager impl methods
before
doing any persistence-related work (whether reading or writing). This
method (actually the entire strategy class) can be entirely
JDO-specific; it
is exposed only to impls of the same strategy and implements no generic
interface.
--a.
----- Original Message -----
From: "Allen Gilliland" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, June 07, 2006 9:25 AM
Subject: Re: Add "notify intent to update" method to Roller
> Well, my first thought is "ugh".
>
> Personally I think that suggestion is actually a step backwards. Our
> current Hibernate implementation requires the same exact thing, each
> operation happens within a Transaction, but we are able to begin
> transactions in a lazy fashion and it's isolated within the Hibernate
> implementation code so that the rest of the code isn't littered with
> Roller.begin() statements everywhere.
>
> If you look in the HibernatePersistenceStrategy class it's pretty
easy to
> see what I mean. Any time one of the hibernate manager impl classes
> requests a Hibernate Session to do some work, a transaction is
> automatically started. Check out
> HibernatePersistenceStrategy.getSession()
>
> Unless there is a *very* *very* strong reason why that can't be done
> in
> JDO then I would much prefer that we not revert to using a
Roller.begin()
> method. The idea is that persistence is supposed to be transparent,
and
> as soon as every time you work on an object you have to wrap it in a
> begin() and flush() method then that's not the case anymore =(
>
> -- Allen
>
>
> Dave Johnson wrote:
>> This is an interesting RFE from Craig Russell:
>> http://opensource.atlassian.com/projects/roller/browse/ROL-1156
>>
>> Perhaps we could call this new method Roller.begin() ?
>>
>> - Dave
>
