nk4um

Right, this is what I mean by going outside the model.  The accessor cannot simply return a representation and allow the ROC expiry model to take care of things, it must also be stateful and hold onto the representation privately, and maybe create a background thread also.

This pseudocode is roughly how this needs to happen:

class MyExpiringAccessor {   private Map liveInstances;   void processRequest(context) {     uri=context.thisRequest.URI;     if (liveInstances.get(uri) != null) {       liveInstances.get(uri).destroy();     }     newInstance n=getNewInstance(context);     liveInstances.put(uri,n);     n.setCacheable();     context.setResponse(n);     n.setWatchdog(new Runnable {       void run() {         thread.wait(300000);         n.destroy();       }     });   } }

Maybe I wasn''t clear. It is certainly possible to achieve the effect you want. Like you say mod-db is a good example of something similar.

The pattern is that the state-transreption transreptor that creates all the connection aspects and manages their lifecycles. The transreptors and accessors have explicit lifecycles and can implement programmatic lifecycles for representations. So for example when the golden thread is cut and a request comes in for that representation, it will call a close method on the old representation and construct and return the new one.

Tony

No, this doesn''t really help.

The implication is that the resource model is inadequate for cases explicitly requiring a lifecycle beyond creation and finalization, and so to do this in NK requires going outside the model.  How does mod-db handle this problem?  A jdbc connection needs to be explicitly closed and waiting for finalization is frequently not sufficient.

I''ll need to think about how to do this some more.

Hi Jeff,

the short answer is no. The design intent of representations is that they are immutable snapshots and as such the management of them in terms of references either in application accessors or by the cache etc is very loose. Because of this they have no specific lifecycle events other than construct and finalize.

A better resource oriented pattern for this would be to have a service that returns a per-use representation. The same golden thread technology can be used behind the scenes to control expiry but the service/accessor itself would manage the lifecycle of the connection and maintain state between requests.

Does this help?

Tony

Pretty straightforward problem here.  I am creating a class to hold a connection to a network server and I want this connection to be held open between requests.  I can use the state-transreption pattern to create the connection, and if I expire that representation (via golden thread or otherwise) then I will get a new connection instead of the old one, but the old one will still be around (consuming resources on the server).  Is there a way to implement a destructor on a cached representation such that when NK forgets about it the destructor will get called soon?  A java finalizer wouldn''t seem to work, as the JVM gives no guarantee about when it will get called, so connections could easily pile up.