On Jan 8, 2008 3:25 PM, Andrea K. <[EMAIL PROTECTED]> wrote:
>
> Hi Alex,
> shared sessions are used only for readonly requests. I shared them because
> of their use.
> It's a web application and requests are various and from various points
> inside app.
> So, many logins and logouts are frequently done, and that the point that
> made me decide to
> share sessions. Also various forum posts talk about this appointing to
> divide readonly session
> from write sessions. Consequently, write operations are managed from another
> web applications and use their own sessions. Nothing is shared when writing.
>
> Any critique is appreciated!
>
> BR,
> Andrea -
>

Thanks for the clarifications Andrea. As I've said with read only
sessions your approach makes a bit more  sense (and probably I got
confused by the synchronized word used in your initial email).

According to your comment, it is the numerous session login/logout
that you've tried to address when sharing the session. But, as far as
I can say: with the pool you login only once per each session
available in the pool (and logout only when you restart the app), so
this cost is completely eliminated. Now, imo it all boils down to
correctly sizing the pool.

As I have researched myself in old versions sharing a read only
session between threads is safe, but as you probably know this is not
guaranteed, so your company should be aware that upon an upgrade the
whole thing may break. I am using a single session shared between
multiple threads myself, and I have warnings everywhere in my app for
this (and due to this and a couple of other dependencies I'm still
stuck with a quite old version).

./alex
--
.w( the_mindstorm )p.

>
> --
> View this message in context: 
> http://www.nabble.com/Shared-session-pool-tp14486499p14689371.html
>
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>

Reply via email to