Object Lifetime Options

[Bill Wishon <Bi...@PictureIQ.com>]

	
Are there any plans to add more object lifetime options to soap services?
	
Right now there are the Application, Session, Request and Page choices for
the lifetime of the service object(s).  For an application I am writing I
would like an ID/timeout based lifetime model which would work something
like this:  

Each request would have an object ID in it somewhere, either as the first
parameter or perhaps in the headers.  Every time a request is received with
a null object ID a new object is created, assigned an ID and inserted into a
hash that lives as part of the servlet context.  If a request with an ID is
received then that ID is used to lookup an object in the hash table of
objects.  If that object is not found then it is an error.  Every n seconds
we scan through the hash table pulling out objects that have expired, where
the time till an object expires is configurable.

By using a lifetime model like this it is possible for me to write client
side code that doesn't know about or can't deal with sessions and yet can
maintain and manipulate many different server-side objects.  Another big
reason for me wanting to do something like this is so that I don't have to
send the object in question back and forth, encoding and decoding it at each
end, because the object is quite large and it would be to slow.

Does this sound reasonable to anyone or am I alone in wanting this kind of
functionality?  If there are others interested I would be willing to
contribute my modifications back to the codebase.

Any thoughts?

-Bill

Re: Object Lifetime Options

[Jean-Noel Gadreau <jn...@activcard.com>]

Seems like a good thing. As far as 3.0 goes, I think we should have
flexible ways for the target objects (such as a pool of identical
objects, non synchronized object, ...).

My $0.02

Jean-Noel Gadreau


Bill Wishon wrote:
> 
> 
> Are there any plans to add more object lifetime options to soap services?
> 
> Right now there are the Application, Session, Request and Page choices for
> the lifetime of the service object(s).  For an application I am writing I
> would like an ID/timeout based lifetime model which would work something
> like this:
> 
> Each request would have an object ID in it somewhere, either as the first
> parameter or perhaps in the headers.  Every time a request is received with
> a null object ID a new object is created, assigned an ID and inserted into a
> hash that lives as part of the servlet context.  If a request with an ID is
> received then that ID is used to lookup an object in the hash table of
> objects.  If that object is not found then it is an error.  Every n seconds
> we scan through the hash table pulling out objects that have expired, where
> the time till an object expires is configurable.
> 
> By using a lifetime model like this it is possible for me to write client
> side code that doesn't know about or can't deal with sessions and yet can
> maintain and manipulate many different server-side objects.  Another big
> reason for me wanting to do something like this is so that I don't have to
> send the object in question back and forth, encoding and decoding it at each
> end, because the object is quite large and it would be to slow.
> 
> Does this sound reasonable to anyone or am I alone in wanting this kind of
> functionality?  If there are others interested I would be willing to
> contribute my modifications back to the codebase.
> 
> Any thoughts?
> 
> -Bill

Re: Object Lifetime Options

[Jean-Noel Gadreau <jn...@activcard.com>]

Seems like a good thing. As far as 3.0 goes, I think we should have
flexible ways for the target objects (such as a pool of identical
objects, non synchronized object, ...).

My $0.02

Jean-Noel Gadreau


Bill Wishon wrote:
> 
> 
> Are there any plans to add more object lifetime options to soap services?
> 
> Right now there are the Application, Session, Request and Page choices for
> the lifetime of the service object(s).  For an application I am writing I
> would like an ID/timeout based lifetime model which would work something
> like this:
> 
> Each request would have an object ID in it somewhere, either as the first
> parameter or perhaps in the headers.  Every time a request is received with
> a null object ID a new object is created, assigned an ID and inserted into a
> hash that lives as part of the servlet context.  If a request with an ID is
> received then that ID is used to lookup an object in the hash table of
> objects.  If that object is not found then it is an error.  Every n seconds
> we scan through the hash table pulling out objects that have expired, where
> the time till an object expires is configurable.
> 
> By using a lifetime model like this it is possible for me to write client
> side code that doesn't know about or can't deal with sessions and yet can
> maintain and manipulate many different server-side objects.  Another big
> reason for me wanting to do something like this is so that I don't have to
> send the object in question back and forth, encoding and decoding it at each
> end, because the object is quite large and it would be to slow.
> 
> Does this sound reasonable to anyone or am I alone in wanting this kind of
> functionality?  If there are others interested I would be willing to
> contribute my modifications back to the codebase.
> 
> Any thoughts?
> 
> -Bill