Actually tou could think about doing a programmatic times lock.
Something like adding a datetime field to the table in question that
is used to denote when the lock will expire. Then in your code you
query the table and check the lock expiration field. Some thing like
the following...
MY_DATA_TABLE
... Some Fields...
... LOCK_EXPIRE DATE NULL
you just have to check the LOCK_EXPIRE field before you let a user
edit the row in question. This will give you a row level expiring
lock.
Don't know if this helps alot, but its an idea.
Joshua T. Pyle
On 8/29/05, Gili <cowwo..bs.darktech.org> wrote:
>
> But... like I keep on saying... this doesn't help if the cache is
> instantiated across different JVMs. In my case I have my webapp using
> one JVM and my admin console using another and both hit the cache. In
> the future I forsee clustering many other JVMs hitting the cache too. So
> I don't see how locking in memory is going to help.
>
> Gili
>
> Gentry, Michael (Contractor) wrote:
> > No, Cayenne isn't "smart" enough to automatically generate an
> > incrementing SQL statement, but you are. :-) I don't know of any ORM
> > that is smart enough to check for that. And, personally, I think it
> > would be a performance drag to add it.
> >
> > I wasn't suggesting locking on a database object. Make a CacheHelper
> > class which you use exclusively to manipulate the cache. Use Java
> > synchronization (on a method or variable, whichever makes more sense in
> > your helper class) to ensure only one thread is monkeying with the cache
> > at any point in time. If you do this, you should be able to use plain
> > old Cayenne DataObjects and fire a single commitChanges() to do it all
> > in one transaction. You might not even need SQLTemplate with this
> > approach. The more I think about it, this might be the simplest
> > solution and will ensure you don't have cache manipulation code
> > scattered about.
> >
> > /dev/mrg
> >
> >
> > -----Original Message-----
> > From: Gili [mailto:cowwo..bs.darktech.org]
> > Sent: Monday, August 29, 2005 11:37 AM
> > To: cayenne-use..bjectstyle.org
> > Subject: Re: Lazily column retrieval
> >
> >
> > > 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/
>
-- Joshua T. Pyle Go has always existed.
This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 14:31:09 EDT