Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory Leak - constructor.cache #46

Closed
howech opened this issue Mar 13, 2012 · 2 comments
Closed

Memory Leak - constructor.cache #46

howech opened this issue Mar 13, 2012 · 2 comments

Comments

@howech
Copy link

howech commented Mar 13, 2012

Items that get stored in constructor.cache do not ever seem to be freed up. Is there a way to make this an LRU cache with a fixed size?

@1602
Copy link
Owner

1602 commented Mar 13, 2012

Of course we can make it LRU with fixed size. But there may be some issues hard to debug. I thinking about disabling cache totally. Generally it is for tracking instances:

post = new Post
post.save (err, p) ->
    // here p and post of course same object (single pointer)
    Post.find post.id, (err, p2) ->
      // here p2 and post the same pointer

But without caching p2 and p1 not the same object, so you can modify both, then save and lost some changes. Let's say we have some case when cached object was removed from constructor.cache, but still used by application code, in the next time we call Model.find new instance will be saved in cache, both instances live. This is a reason why it should be touched carefully.

But more complicated saving logic looks like solition:

object.save ->
IF object in cache?
THEN
   IF cached object the same pointer?
   THEN just save
   ELSE update cached object, merge pointers, save
ELSE reload from database to cached instance, object.save()

on updating cached instances, need track dirty attributes. now we only have problem in situation where both cached and not cached objects have modifications on same attribute.

what do you think?

@howech
Copy link
Author

howech commented Mar 15, 2012

I think that unless you are guaranteed to be the only client of the database, you can never be sure that your cached object represents the current state of the database.

I think that all of these problems are preferable to my process crashing because it has run out of memory with cached objects!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants