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
>
