On Thu, Aug 4, 2011 at 2:53 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
>
> On Thu, Aug 4, 2011 at 6:35 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> > Hi!
> > On 8/4/11 5:34 AM, Lars Schultz wrote:
> >>>
> >>> Do not keep object references, keep object IDs. This would make your
> >>> code a bit more verbose and a bit slower, but weak refs would
> >>> essentially do the same anyway.
> >>
> >> This is like saying: do not use objects at all and use the DB for
> >> storage. verbosity and slowness is something I'd like to prevent.
> >
> > No, it's not even remotely like that. Using one intermediary function and
> > doing the DB call is orders of magnitude apart. You asked how you can solve
> > the problem, I showed you how. You can claim you don't like the solution,
> > that's fine, everybody has his own taste. But you can't claim there's no
> > other solution.
>
> maybe it's just me, but I not fully understand your solution.
>
> "I'm not sure I understand why you need week refs there - can't you
> just always use $prodDb->getProduct(1) and when you don't need it
> anymore just do $prodDb->drop(1)? Or let it drop it whenever it wants
> to?"
> "Do not keep object references, keep object IDs. This would make your
> code a bit more verbose and a bit slower, but weak refs would
> essentially do the same anyway."
>
> from that, my guess is that you propose that nobody should hold a
> reference for the product, but always use the returned object from
> getProduct() on the fly.
> you also suggest that ProductDatabase should also remove the cached
> object when appropriate.
> did I get interpreted your solution correctly?
>
> I have some problems with this approach:
> - you cannot guarantee/force the contract that the result of the
> getProduct cannot be stored.
> - in a loosely coupled system, it is hard to tell when "you don't need
> it anymore".
> as you and Lars both mentioned we only care about freeing the cache,
> because we have memory constraint.
> Lars mentioned that currently he manually checks the memory usage, and
> free the cache if needed:
> http://www.mail-archive.com/internals@lists.php.net/msg52423.html
> of course one could also write some algorithm, which removes records
> from the cache either randomly, or as Jonathan suggestion doing
> something like LRU/MRU.
> with Weak References, you shouldn't care about that, the gc would do
> it for your, albeit in a less sophisticated way: if the gc root buffer
> is full, then free every item which isn't used at that time.
> and of course you can combine the WeakRefs and some cache algorithm as
> Jan did in his blogpost. (good article btw. and also good to see that
> Benjamin Eberlei from the Doctrine project looking into the possible
> use cases for them)
>
> so as I see you didn't really addressed the proposed use-case of the
> Weak References, just stated what everybody is aware of: one can cache
> and free objects "manually" without the need of Weak References.
> and while that is true, I still think that this could be a great asset
> for creating high quality components.
>
To make sure I understand the advantages of weak references paired with
caching, this is what I understand:
1) While in the size-limited cache, an object would never be garbage-collected.
2) If the size-limited cache decides to prune an object, and the
object is still
being referenced in a variable, the weak reference map will allow you to avoid
making a call to the db, and avoid having a duplicate object.
3) If the size-limited cache decides to prune an object, and the object is not
referenced anywhere, the object may be gc'ed at any time, meaning the weak
reference may not be valid(). However, there may be some time between
garbage collection that the object is still available if the code
requests a new
instance of the object. This behavior could not be relied on, but might avoid
some small amount of traffic to the db.
So the advantage is mostly in case 2, where we avoid the duplication of an
object. For example, in code like this(which is obviously silly, but
given a more
complex application might happen):
function foo() {
$bar = Bar::get(1);
$bar->baz = 2
anotherFoo();
$bar->save();
}
function anotherFoo() {
$bar = Bar::get(1);
$bar->baz = 4;
$bar->save();
}
If the cache pruned the Bar object with id 1 before anotherFoo() was
called, without
weak references, we would have two different $bar objects. With weak
references,
they still refer to the same object.
Are there other advantages I'm missing?
If not, I see some advantage to Weak References, but I'm glad to be
playing with
them in PECL to see exactly how much real advantage they would give.
Thanks,
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
