> Suppose that I receive a request from the client. I start processing the
> request, but it's possible that I'm waiting after the database before
> continuing the process. The request from the client will be blocked until the
> database return the results and after that the server will be able to
> continue to process the client request.. and after all that. the request will
> receive the response.
>
>
> ok.. just to understand outside grizzly, suppose we used selector , from
> the thread on which we use the selector.. it will block. Yes it make
> sense.. Even if the database have a pool.
>
> I think I get it.. without the suspendable filter we would have to do
> that : if the database pool is full.. to avoid the block, we should create
> another thread.. that will do polling and when the database is available.. bla
> bla bla.. (like you send below)
>
>
> suppose this case : we have a pipeline of 10. All the 10 connectors are
> currently use. so the suspendablefilter.. is pausing the current thread..
1)The suspendablefilter does not pause and not block the work Thread it just saves all the
current work Thread state. The then free work Thread can continue to serve other
connections.
2)When the database transaction is ready the Suspendable.resume() just grabs
all the saved state and gets any work Thread to continue with the before saved
state.
So though suspend - resume you try to keep the Grizzly Worker Thread Pool from blocking.
> so another thread will start right ? if yes.. what will happen if all the
> connectors are use and one that was suspended resume ?
>
>
>
> 2008/7/4 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com>:
>
> Salut,
>
>
>
> Survivant 00 wrote:
>
> I don't understand when to use SuspendableFilter.
>
>
> Suppose that I receive a request from the client. I start processing the
> request, but it's possible that I'm waiting after the database before
> continuing the process. The request from the client will be blocked until the
> database return the results and after that the server will be able to
> continue to process the client request.. and after all that. the request will
> receive the response.
>
>
> I have a basic client/server application. The clients can send multiples
> requests to the server, and the server will response when it able to
> process them.
>
> so I don't understand what the SuspendableFilter will add to that .
>
> can someone explain it to me with a example ?
>
>
>
> Using your scenario, you will use the SuspendableFilter to avoid blocking
> a thread until the database returns the result. The database operation may
> takes a while to return, so freeing the Thread and resuming it later will
> help avoid all the thread blocked on a database operation.
>
> Another example is when you have more Threads than database connection. In
> that case, some thread may block on the database pool, waiting for a
> connection to be available. In that scenario, the Thread are wasted, waiting for
> a connection. A better approach would consist of suspending the execution
> (freeing the thread), and once database connection are available, resume
> the operation by getting back a thread.
>
> Hence the SuspendableFilter could be used for doing such suspend/resume.
> But with the new api I've discussed here[1], you will be able to do the same
> operations (suspend/resume) without the needs of using the
> SuspendableFilter.
>
> Does it help?
>
> Thanks
>
> -- Jeanfrancois
>
> [1] https://grizzly.dev.java.net/issues/show_bug.cgi?id=186
>
>
>
>
>
> thanks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
>
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer