roller-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anil Gangolli" <>
Subject Re: Add "notify intent to update" method to Roller
Date Sun, 02 Jul 2006 16:57:35 GMT
I guess I'm also not understanding the need to introduce an 

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 


----- Original Message ----- 
From: "Allen Gilliland" <>
To: <>
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 <> 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" <>
>>> To: <>
>>> 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:
>>> >>
>>> >>
>>> >> Perhaps we could call this new method Roller.begin() ?
>>> >>
>>> >> - Dave
>>> >

View raw message