i think the point of a restful service is that it is stateless. i prefer to use cookies as a means of maintaining session authentication across requests and not state management.
you should look at moving application state into the back end and letting the database handle state management across requests.
if your load is too great for 1 database, you can shard the db by some functional property of the request. this way you can handle any volume of load yet without the complexity of managing and replicating state across front end web servers with load balancing.
the database has sophisticated transaction isolation for exactly these scenarios that you will never be able to replicate on the front end.
hth,
cam
On 25/02/2011, at 9:31 AM, Leo Romanoff wrote:
>
> Hi Jan,
>
>
> algermissen1971 wrote:
>>
>> Leo,
>>
>> make your process a resource that changes state over time.
>>
>
> I'd love to do so. To some extent, our current RESTful API follows this
> idea. We use the patterns like:
>
> POST /service/startProcess -> would return the process id of newly started
> process
> GET /service/process_id/state_resource_path
> DELETE /service/process_id
>
> But as I mentioned, this process has a LOT OF state. Replicating its state
> between cluster nodes is very difficult and inefficient for different
> reasons. Therefore, only the cluster node owning the process can process
> requests related to it. And I do not see yet how your proposal helps in this
> regard. Or may be I misunderstand what you say?
>
> -Leo
> --
> View this message in context: http://jersey.576304.n2.nabble.com/Providing-a-stateful-JAX-RS-service-in-a-cluster-tp6063881p6063914.html
> Sent from the Jersey mailing list archive at Nabble.com.