Saturday, April 16, 2005, 3:58:11 PM, Julien Viet wrote: > invalidate the cache : > > - time based invalidation, you say that an entry is valid for 1 minute > for instance > - notification, you can use JCR observations mechanism to remove entries > from the cache
Neither works. As I said "Of course no hazards and unpredictable delays are allowed after the repository was modified", and it can't be achieved with asynchronous event notifications and time based invalidation. It's so obvious that I guess it was not clear what I meant with "no hazards and unpredictable delays", so let me tell a simple example: You have an MVC web application, and for each page visit you use script (like a Jython script) and a HTML template. These are from the Web application point of view mycms.Script objects (stores the pre-parsed (compiled) script) and mycms.Template objects (stores the pre-parsed template), and from the JCR point of with nodes (maybe of type mycms:template and mycms:script). These object are seldom changed, but if they are, you have certain expectations. Assume I start transaction, modify a script and a template in the repository, and then commit the transaction. Now, when you start a new transaction later (e.g. for satisfying a HTTP request), you want to see the new objects, not the old ones, especially if you want to check what you have just committed. Also, you don't want to face with inconsistent states, where for example the script object is in its old state, and the template object is in new state (since in general the old template works correctly only with the old script, and the new template works correctly only with the new script, and mixing the two will result in error 500 pages and other malfunctions). It's basically the same as the ACID thing of the RDBMS-es, and surely I don't need to explain why is this absolutely important for server side applications. Now, on the JCR level everything is "ACID" (well, it can be if transactions are supported etc). But you will seldom use raw JCR without some kind of object mapping behind it, right? And if all the "ACID" loses with the object mapping (as the cache can't be kept precisely in sync with the content of the repository), then in practice you have just trashed the ACIDity of the JCR repository. Does anybody get what I'm saying? You have to modify sites while they are running... think about a big "portal", so you need that ACID very much. > cheers > > Daniel Dekany wrote: > >>I suppose most applications want to work with objects like mycms.User, >>mycms.PageTemplate, myapp.Book, etc., rather than directly with the tree >>of items that JCR shows. I don't see what's the intended way of doing >>this. With a concrete example: I would like to store page templates in >>the repository, which are complex and frequently used objects, so they >>shouldn't be recreated from a binary property (or from string string >>property, whatever) every time they are read from the repository (that >>is, for each page hits). I could use cache in front of JCR that caches >>the template objects, but how to ensue that the cache is in sync with >>the repository? Of course no hazards and unpredictable delays are >>allowed after the repository was modified. >> >>What's the planned way of doing things like this? >> >>(I know this is not a Jackrabbit but a JCR question and I apologize for >>that, but I didn't found a more suitable public list.) -- Best regards, Daniel Dekany
