We're very close to having everything in place for the videos and slides of the Architects Weekend.  All being well they'll go live tomorrow.

As for feedback - If its good, put it on the forum. If its bad, send it in email ;-)   Naaaaaaa.  Whichever you feel comfortable with - if it contains confidential information related to your own products then obviously send it as email.

Cheers,

P.

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

Are the slides from the architect's weekend available anywhere?  I'm especially interested in the presentation on the new DPML, since the documentation in the preview is just a quick reference sheet.

Also, would you prefer we put our feedback on the preview here for community discussion, or would you prefer I send them directly via email?

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.

Shane,

Good feedback about usage examples.

I am working on NetKernel 4 documentation right now and your comment is a good reminder about what we need. If you have any other thoughts about how the documentation can be improved for NetKernel 4, please let us know.

Cheers -- Randy

Perfect, that is exactly what I needed.  This is a case where a usage example helped out a lot.  Thank you Peter.

Hi Shane,

Yes you are correct - you can apply throttling to any service.

You need to use the active:throttle accessor...

http://docs.1060.org/docs/3.3.0/book/developerreference/doc_ura_throttle.html

and use the mapper pattern to route requests for your service to the throttle first.  You set this up in your module with a rewrite like this...

<rewrite>   <match>active:myservice(.*)</match>   <to>active:throttle+id@my:throttle:id+configuration@ffcpl:/myconfig.xml+uri@active:myservice$1</to> </rewrite>

id is a unique id for the throttle queue since active:throttle manages any number of different queues at once.

Does this make sense?

Cheers,

Peter