Do HiveMind & Co. provide stateful services? I don't think so. Should they? As I'm growing increasingly fond of the Hibernate long-session-pattern, I do think so. You'd probably need some means of attaching/detaching some client-id to a thread (a servlet-filter, typically), so, after that the container could maintain same (service-id, client-id) to service-implementation map. In the servlet-case parallel request from the same client could be blocked (synchronised on) - actually this should be the general case - clients wanting to be served concurrently must provide thread id's instead of client ids.
HiveMind's pooled services should already be quite close, only, the pool needs to become aware of the client-id's -- I need to have a look at them.
2 comments:
You can add your own service lifecycle model for this purpose. The trick would be to have some place that identifies the current "user" or "session" and has an ability to store that data between "requests". Really falls into terms familiar to the Servlet API. Geoff Longman has mentioned looking to create a session-persistent service lifecycle model.The big issue is clustering: I don't put things into HiveMind or Tapestry that won't work in a cluster.
I took your comment as an encouragement to just go ahead and try it (new service-model depending on a state-persister-service which can be fed a servlet-session via a filter). And I was thoroughly surprised how easy that was! HiveMind really feels very good. I just looked into the code to guess how it works - and things worked as I thought they should work - that's really great fun!
Post a Comment