Comments on: Transparent Persistence: It’s ok that it isn’t totally transparent! http://almaer.com/blog/transparent-persistence-its-ok-that-it-isnt-totally-transparent blogging about life, the universe, and everything tech Sat, 08 Sep 2012 07:06:53 -0700 http://wordpress.org/?v=2.8.4 hourly 1 By: Brian McCallister http://almaer.com/blog/transparent-persistence-its-ok-that-it-isnt-totally-transparent/comment-page-1#comment-6748 Brian McCallister Thu, 02 Sep 2004 15:30:29 +0000 http://almaer.com/blog2/transparent-persistence-its-ok-that-it-isnt-totally-transparent#comment-6748 We are deifnately off topic for Dion's post. I am talking about a different way to view the cache and system design, which instead of the cache being the "check here before you load this thing" is a "go through it to load" where the cache handles the database access and the client talks to the cache. I was, and will in the future, try to avoid calling it a cache though as a cache has a very different connotation. There are big drawbacks -- if you cannot use optimistic transactions on the majority of the data there is no benefit at all, for example. Also, the mapping has to be extremely good or the small impedence (collection on bar contains foo, foo has reference to bar and the ref or colelction changes -- the relationship is one way in the db, what happens?) problem will magnify quickly. These are solvable problems though, and I think the benefits probably outweigh the drawbacks in the majority of cases. The process of implementing it, though, is basically implementing a local database backed by a remote database. -Brian We are deifnately off topic for Dion’s post. I am talking about a different way to view the cache and system design, which instead of the cache being the “check here before you load this thing” is a “go through it to load” where the cache handles the database access and the client talks to the cache.

I was, and will in the future, try to avoid calling it a cache though as a cache has a very different connotation.

There are big drawbacks — if you cannot use optimistic transactions on the majority of the data there is no benefit at all, for example. Also, the mapping has to be extremely good or the small impedence (collection on bar contains foo, foo has reference to bar and the ref or colelction changes — the relationship is one way in the db, what happens?) problem will magnify quickly.

These are solvable problems though, and I think the benefits probably outweigh the drawbacks in the majority of cases. The process of implementing it, though, is basically implementing a local database backed by a remote database.

-Brian

]]>