Re: not caching to object in code interface to database?

One problem with a cache is if two parts of the program have objects for the same record at the same time. They can fiddle with their local copies and think that they've made the changes they want to make to the database, but the last one to commit wins. Or maybe the record winds up in a strange state. One of them may make a change, and the other never sees it.

If you're planning to cache things at all, you might as well cache entire records at a time. When the object needs any field, get every field. That way you hit the database fewer times.

If you don't cache anything, the performance may indeed be really bad. It might be bad but acceptable—that's a personal preference. Have you tried it?

Comment on Re: not caching to object in code interface to database?

Replies are listed 'Best First'.
Re^2: not caching to object in code interface to database? by leocharre (Priest) on Jan 22, 2009 at 20:18 UTC
Yeah.. good point on multiple objects. I have it so they're singletons sometimes. They can be locked for commit, etc.. I also have it as you mentioned- I fetch all on load triggered and save all at the same time (please excuse my pseudocode). There are some things, that if they are heavy, I hold off on until they are called. No I really haven't tried it.. I'm curious though. I bet this is wildly different in various db daemons, etc. For example, if the server is local, obviously if you are using autocommit, etc etc etc. It just felt creepy wrong to do it that way- but.. maybe the tech is up it these days.. hmm..... What's really cool is that you actually wouldn't be changind the api at all- most of it.. just the internals. So, I could take one of my objects, rename it and rework it to act that way.. hm.. more to come about this sooner or later.	[reply]

Replies are listed 'Best First'.

Re^2: not caching to object in code interface to database?
by leocharre (Priest) on Jan 22, 2009 at 20:18 UTC

I also have it as you mentioned- I fetch all on load triggered and save all at the same time (please excuse my pseudocode). There are some things, that if they are heavy, I hold off on until they are called.

No I really haven't tried it.. I'm curious though. I bet this is wildly different in various db daemons, etc. For example, if the server is local, obviously if you are using autocommit, etc etc etc.

It just felt creepy wrong to do it that way- but.. maybe the tech is up it these days.. hmm..... What's really cool is that you actually wouldn't be changind the api at all- most of it.. just the internals. So, I could take one of my objects, rename it and rework it to act that way.. hm.. more to come about this sooner or later.

[reply]