Add "notify intent to update" method to Roller

[Dave Johnson <sn...@gmail.com>]

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

Re: Add "notify intent to update" method to Roller

[Anil Gangolli <an...@busybuddha.org>]

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" <al...@sun.com>
To: <ro...@incubator.apache.org>
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 <an...@busybuddha.org> 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" <al...@sun.com>
>>> To: <ro...@incubator.apache.org>
>>> 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
>>> >
>>>
>>>
>

Re: Add "notify intent to update" method to Roller

[Allen Gilliland <al...@sun.com>]

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 <an...@busybuddha.org> 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" <al...@sun.com>
>> To: <ro...@incubator.apache.org>
>> 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
>> >
>>
>>

Re: Add "notify intent to update" method to Roller

[Dave Johnson <sn...@gmail.com>]

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.

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.

- Dave


On 6/8/06, Anil Gangolli <an...@busybuddha.org> 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" <al...@sun.com>
> To: <ro...@incubator.apache.org>
> 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
> >
>
>

Re: Add "notify intent to update" method to Roller

[Anil Gangolli <an...@busybuddha.org>]

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" <al...@sun.com>
To: <ro...@incubator.apache.org>
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
> 

Re: Add "notify intent to update" method to Roller

[Allen Gilliland <al...@sun.com>]

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