RE: Lazily column retrieval

From: Gentry, Michael \(Contractor\) ("Gentry,)
Date: Mon Aug 29 2005 - 14:20:09 EDT

  • Next message: Gili: "Re: Lazily column retrieval"

    Oh yeah, SQLTemplate bypasses the in-memory data object graph. So you
    don't get optimistic locking with it. That's why if you do DELETEs/etc
    in it, you can get your data object graph out of sync if you aren't
    careful.

    /dev/mrg

    -----Original Message-----
    From: Gili [mailto:cowwo..bs.darktech.org]
    Sent: Monday, August 29, 2005 1:24 PM
    To: cayenne-use..bjectstyle.org
    Subject: Re: Lazily column retrieval

            What about if I do this?

            begin transaction
            increment num_references using SQLTemplate
            add/remove cache entries using object queries
            end transaction

            This should ensure everything occurs from within a single
    transaction,
    while avoidding collisions for num_references. I assume that even if
    optimistic-locking is enabled for the table containing num_references,
    it'll be ignored if I use SQLTemplate?

            Basically I want to selectively increment num_references without
    any
    optimistic locking. The same goes for deleting cache entries. If I
    delete a cache entry and it has been modified since I last viewed it
    (i.e. its score changed) I expect the delete to go through anyway.

            Is there a way to control optimistic locking on a per-query
    basis like
    this? or am is it controlled on a per-table basis?

    Thanks,
    Gili

    Gili wrote:
    > > Well, sending an "UPDATE image_cache_stats SET num_requests =
    > > num_requests + 1" is highly unlikely to fail (your DB would have to
    > > tank, in which case there is nothing Cayenne can do).
    >
    > Regarding "UPDATE image_cache_stats SET num_requests =
    num_requests
    > + 1" I am curious whether Cayenne is smart enough to issue this SQL
    > statement itself or is it impossible for it to know whether I am
    > incrementing a field versus setting it to an explicit value?
    >
    >> Are you trying to limit the image_cache_stats to a set size? You
    could
    >> do that, adding new entries and deleting others and then do a
    >> dataContext.commitChanges(), but that seems like more trouble that it
    is
    >> worth.
    >>
    >> Could you not leave old entries in the image_cache_stats table do a
    >> query against it with an ORDER BY and a LIMIT to control the data
    coming
    >> back? I'd let the database do the work since it is good at it. If
    you
    >> did have a need to prune the size of the table, you could always
    issue a
    >> DELETE using SQLTemplate to get rid of rows that fall below a certain
    >> threshold.
    >
    >
    > That would work too but it won't guarantee the cache size is less
    > than a certain value. I *almost* do what you say though. I do ORDER BY

    > and remove rows I get back until the total cache size is under its
    > expected limit.
    >
    >> I guess what I'm saying is don't be afraid to use an SQLTemplate when
    >> you have a valid need for it (that's what I do when it makes sense).
    >> Let the database do work for you when appropriate.
    >>
    >> As for the consistency issue, as soon as you refetch the table data,
    >> you'll be up-to-date again in Cayenne. It might make sense to put
    all
    >> of this logic in a helper class (complete with it's own DataContext)
    to
    >> manage it. You should use a synchronize block around the update code
    to
    >> let Java serialize that portion.
    >
    >
    > But this still does not guarantee consistency. If I use two
    separate
    > transactions: one for incrementing num_requests, and another for
    > actually inserting/removing cache entries, there is no guarantee both
    > will succeed or fail together.
    >
    > Secondly, in the Hibernate documentation they explicitly warn not
    to
    > sychronize on database objects in memory because this does not
    guarantee
    > they won't actually get modified. The only safe place to lock on
    objects
    > is in the database. In Hibernate, for example, each thread sees a
    > difference object instance which points to the same database row.
    > Synchronizing in one piece of code in one application will not prevent

    > another piece of code in another application will attempting
    modification.
    >
    > Gili
    >

    -- 
    http://www.desktopbeautifier.com/
    



    This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 14:20:13 EDT