Hi Darren,

Did you implement anything from what Peter described in the Distributed-Cache-Or-Resources.pdf? If yes, could you share your implementation or at least some specifics.

@Peter Since you wrote the PDF above, did you or the NK community implement something concrete based on your guidelines?

Thanks,

mircea

Thanks I''ll take a look.

Hi Darren,

When people start to play with NK and understand that it has a cache sooner or later this question gets asked.  I''ve put together some notes that I hope will explain this...

http://resources.1060research.com/docs/2009/12/Distributed-Cache-Or-Resources.pdf

Hopefully these show that if you step away from the physical problem and think about the resources first - then a quite straightforward pattern falls out.

Hope this helps.

Peter

Apologies my question is similar to another on here about using Terracotta for NK caching but it''s a little old and I wanted to ask specifically about NK4:

I was wondering if there''s any hooks to plug-in a custom cache implementation to be configured for use on certain resources...  can''t find any docs on the cache for NK4 though(?)

The reason I''m interested is that at my company we use XSL to transform lots of fairly large XML documents into HTML.  Lots and large enough that ideally we should be a. persisting the output between runs of NetKernel and ideally b. sharing the output between instances of NetKernel.

Focusing on the persistence aspect, I had thought a file based cache backing up the in memory cache would be useful (even if it wasn''t shared between NK instances in the cluster).

I had thought about whether such file based cache could even just be a shared directory.  But that''s risky because of race conditions where two NK machines could be trying to write a file at the same time right.

Alternatively, for the sharing part maybe a database storing the generated html as a CLOB would be better...

In either case, my thought had been that if a request is made for a resource, the "persistent cache" should be checked first, and if the resource isn''t found there, then the actual XSL transform should be run, and the result stored back in the "persistent cache" and returned.

In fact what might work well for us would be the idea that simply deleting the file for a certain document from this "cache" (or the appropriate record from the database in the other design) should be the clue to re-transform the XML - i.e. that should be the equivalent of "breaking the golden thread".

I think Peter had already clued me in to the idea that it''s semantics whether what I''m talking about is a "custom cache" versus just an application level "persistent data store".

In either case, I''m wondering if anybody''s already built a module that does something similar (for a moment I thought the "failover persistent data store" was similar but then I realized it wasn''t).

Otherwise if anybody has some tips/thoughts about how to build it any advice would be welcome. 

e.g. It seems like I should be able to accommodate either the file based or database based "persistent cache" by placing it behind the "persistent data store"/"pds" service right. 

And then is there an obvious way I can make this general/reusable?  It''s simply that I''d make my own module that the resources that should be "persistence cached" should be requested "through"?  Something like "active:persistentCache" where an "operator" is the URI for the resource to be requested?  (this is hinted at in the Terracotta cache thread here on the forum).

And how would I make sure the NK4 in memory cache doesn''t interfere with the behavior I''m after?  i.e. It''s no problem if the resource is retrieved from the in memory cache if it''s also in the "persistent cache" area, but if I really do want the "convenience" of being able to manually delete from the persistent cache area as the sign to "regnerate" the resource, I have to be sure the in memory cache gets invalidated in that case.

I was thinking I need to do an EXISTS on each request for a resource.  Or am I better off using the golden thread pattern after all...

Sorry for the long message - any advice is appreciated...