> Another solution, IMHO, is to make sure all these objects are only used
> within the thread they where allocated for. Briefly, add a package scope
> setThreadID() method to the classes that implement pooled objects like
> this and let the container call this method with the current thread ID
> before it delivers the object to the application. Then compare the
> current
> thread ID with the assigned thread ID in all methods the application can
> call. If they are not the same, throw IllegalStateException.
Well, that's a great idea - but it means adding a native method (
currentThread ) to absolutely all calls to all classes in the servlet API.
I did a test some time ago ( in another context ) - it's not a huge hit,
but it is visible.
Of course, the alternative ( either a sync() block if a pool is used or
garbage collection if the facade is not recycled ) may be as expensive,
but I was hoping that it can be done only for "untrusted" apps.
( on the other side, it's also possible to do
if( untrusted && Thread.currentThread() != myThread ) ... ) )
I'll try both and see what happens.
> Again, the spec is not clear on this. Maybe it needs to be clarified
> with regards to how the container-objects can be used by the application
> (some attempts to clarify this is being added to the JSP 1.2 spec with
> regards to tag handler classes).
One thing is clear - the current implementation ( at least 3.x ) doesn't
do any synchronization on request/response calls - if a servlet is using
more than one thread it's up to the servlet author to synchronize.
( most calls do not need any synchronization anyway, but it hasn't been
tested or verified ).
It would be nice to know that servlets are not allowed to create or use
threads ( and I don't think too many do that anyway ).
Thanks Hans.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
