Yeah, fully agree - but implementing a filter i'm sure that my locks are
removed. The workflow i think is now:
->Servlet -> JSP -> Filter
Thanks for your solutions.
>>So I don't like the idea to use a filter to allocate and deallocate
resources.

The other solution is to overwrite the _jspService method to put the code
into the finally section, or an eventhandler when the page was released
(this indeed i would prefer), but don't know exactly how to do it.

Regards
Reto

-----Urspr�ngliche Nachricht-----
Von: Ralph Einfeldt [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 24. Januar 2002 10:08
An: Tomcat Users List
Betreff: AW: Tomcat - Request Handling


I don't think that there is something like a general best
place. It depends on design of the application.

I like to keep the timeframe as short as possible where
resources like databases or memory are allocated. That has
for us the implication that the allocation of a resource
is as near as possible to it's use and so is the deallocation.

So I don't like the idea to use a filter to allocate and
deallocate resources.

Filter are for me tools to modify the request or the response
or a place to do authentication and things like that.

I admit that this is a quite personal standpoint.

Some ways to get a better idea what happens:
  - If you are using unix/linux send a kill -QUIT <pid> to
    the vm. Then you will get a stacktrace for each thread in
    the core file. (I'm not shure if this is right in the
    windows world: start tomcat in a console so that the
    console stays open and hit something like control-z in the
    console window)
  - Attach a debugger and look at the stack for the threads
  - Use log messages to get a better idea what's the last
    thing that happens in each request.

> -----Urspr�ngliche Nachricht-----
> Von: Reto Badertscher [mailto:[EMAIL PROTECTED]]
> Gesendet: Donnerstag, 24. Januar 2002 09:34
> An: Tomcat Users List
> Betreff: AW: Tomcat - Request Handling
>
>
> Thanks for your help.
> I thought that a filter would be the best place to release resources?
> I'll check for deadlocks - that seems to be pretty hard.
>
> Reto
>

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Reply via email to