Feasibility question

[Iain Downie <ia...@bto.org>]

Hi List,

relatively new to Tomcat, so excuse the possible repetition / naivety of
this posting. We currently have an expanding web application running. We are
thinking of dividing it up into more user-friendly chunks (different
applications), allowing us to control each application more easily (stop one
without affecting others etc.). My question is, is it possible to pass
session info between many different applications?

For example, these are our surveys, which we want as different apps.
1. Login and generic registration
2. Spring birdwatch
3. Garden birdwatch
4. Other survey and so on.
They will all be attached to one Oracle installation.

Currently, 1 and 2 are combined, so no problem with session info. But is it
possible to transfer the user details between these apps, so that someone
who is in Spring, can move over to Garden without having to login again?

I'm not looking for the solution (for now), just to know if it is possible
or not.

Thanks, hope someone can suggest some pointers
Iain


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Feasibility question

[David Cassidy <da...@twocats.co.uk>]

Iain

Put bluntly if these use a different WEB-INF directory then the long and 
short of it
is no.

sorry

D


Iain Downie wrote:

>Hi List,
>
>relatively new to Tomcat, so excuse the possible repetition / naivety of
>this posting. We currently have an expanding web application running. We are
>thinking of dividing it up into more user-friendly chunks (different
>applications), allowing us to control each application more easily (stop one
>without affecting others etc.). My question is, is it possible to pass
>session info between many different applications?
>
>For example, these are our surveys, which we want as different apps.
>1. Login and generic registration
>2. Spring birdwatch
>3. Garden birdwatch
>4. Other survey and so on.
>They will all be attached to one Oracle installation.
>
>Currently, 1 and 2 are combined, so no problem with session info. But is it
>possible to transfer the user details between these apps, so that someone
>who is in Spring, can move over to Garden without having to login again?
>
>I'm not looking for the solution (for now), just to know if it is possible
>or not.
>
>Thanks, hope someone can suggest some pointers
>Iain
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>  
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Feasibility question

[peter lin <pe...@labs.gte.com>]

No problem if security isn't needed. From the description, it doesn't
look like it or atleast doesn't look obvious. You can also use Oracle to
store session, but then you're dealing with a totally different set of
headaches.

just have multi-tiered security, so that only one server allows profile
management and the others can't. Unless there's something critical about
surveys and garden birdwatch.

peter

Steve Ahlstrom wrote:
> 
> No problem if you use cookies.
> 
> -----Original Message-----
> From: Iain Downie [mailto:iain.downie@bto.org]
> Sent: Monday, July 08, 2002 8:12 AM
> To: tomcat-user@jakarta.apache.org
> Subject: Feasibility question
> 
> Hi List,
> 
> relatively new to Tomcat, so excuse the possible repetition / naivety of
> this posting. We currently have an expanding web application running. We are
> thinking of dividing it up into more user-friendly chunks (different
> applications), allowing us to control each application more easily (stop one
> without affecting others etc.). My question is, is it possible to pass
> session info between many different applications?
> 
> For example, these are our surveys, which we want as different apps.
> 1. Login and generic registration
> 2. Spring birdwatch
> 3. Garden birdwatch
> 4. Other survey and so on.
> They will all be attached to one Oracle installation.
> 
> Currently, 1 and 2 are combined, so no problem with session info. But is it
> possible to transfer the user details between these apps, so that someone
> who is in Spring, can move over to Garden without having to login again?
> 
> I'm not looking for the solution (for now), just to know if it is possible
> or not.
> 
> Thanks, hope someone can suggest some pointers
> Iain
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Feasibility question

[Steve Ahlstrom <sa...@americanisp.net>]

No problem if you use cookies.

-----Original Message-----
From: Iain Downie [mailto:iain.downie@bto.org]
Sent: Monday, July 08, 2002 8:12 AM
To: tomcat-user@jakarta.apache.org
Subject: Feasibility question


Hi List,

relatively new to Tomcat, so excuse the possible repetition / naivety of
this posting. We currently have an expanding web application running. We are
thinking of dividing it up into more user-friendly chunks (different
applications), allowing us to control each application more easily (stop one
without affecting others etc.). My question is, is it possible to pass
session info between many different applications?

For example, these are our surveys, which we want as different apps.
1. Login and generic registration
2. Spring birdwatch
3. Garden birdwatch
4. Other survey and so on.
They will all be attached to one Oracle installation.

Currently, 1 and 2 are combined, so no problem with session info. But is it
possible to transfer the user details between these apps, so that someone
who is in Spring, can move over to Garden without having to login again?

I'm not looking for the solution (for now), just to know if it is possible
or not.

Thanks, hope someone can suggest some pointers
Iain


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Feasibility question

[Iain Downie <ia...@bto.org>]

Thanks to all those who replied on my feasibility question (particularly
Andy and Will). The responses were varied, from 'not possible at all'
through to 'cookies' and onto 'singleton classes' and 'DB accessing'. All
very informative, and food for thought - should make for an interesting
application design.

Thanks
Iain


----- Original Message -----
From: "Will Hartung" <wi...@msoft.com>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Monday, July 08, 2002 7:05 PM
Subject: Re: Feasibility question


> To wit he means that with the built-in session management, you pretty much
> don't have to do anything.
>
> It all comes down to how much information you need to share across
> applications.
>
> If you want to store the stuff in memory, then the Singleton class in the
> system classpath mentioned previously will work fine, otherwise you need
to
> persist it to something (DB typically). The only major detail to this is
> that you can't change the Singleton class without restart Tomcat, but
> they're usually pretty simple and locked down fairly early in the design
> process to where this is usually not a problem.
>
> If the amount of info is small, it can all be stored in a cookie or on the
> URL.
>
> If it's simply a single sign-on token, then a cookie would be your best
bet.
>
> The biggest detail with the session management is cleaning up afterwards.
> You'll need some mechanism that dumps the sessions after they have
expired.
> This is something that comes "free" with the built-in session management,
> but, of course, only works for a single webapp.
>
> If you're persisting the session info to a DB, then you'll need some kind
of
> process that sweeps through the sessions and deletes the expired ones.
> There's no reason to get overly complicated about it, it can easily be
> integrated in the routine that creates a session for a new connection. You
> can either just go brute force and delete all of the session info for
> expired sessions every time (this will cost roudtrips to the DB, but odds
> are pretty good they won't be doing much when they get there), or you can
> use a singleton base counter and run the sweep, say, every 100
connections,
> or whatever.
>
> Or you can give a rip, "disk is cheap", and run a simple process once a
> hour/day/week/month. All depends on your load.
>
> For an in memory singleton based manager, you could basically throw all of
> the sessions onto a FIFO queue. Everytime the session is accessed, it gets
> moved back to the head of the queue. Then, your periodic sweeper can
simply
> start at the tail of the queue (all of the oldest sessions) and compare
> timestamps until you've reached your time out limit. All of those sessions
> that have expired are tossed aside for the GC to deal with.
>
> Regards,
>
> Will Hartung
> (willh@msoft.com)
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Feasibility question

[Will Hartung <wi...@msoft.com>]

To wit he means that with the built-in session management, you pretty much
don't have to do anything.

It all comes down to how much information you need to share across
applications.

If you want to store the stuff in memory, then the Singleton class in the
system classpath mentioned previously will work fine, otherwise you need to
persist it to something (DB typically). The only major detail to this is
that you can't change the Singleton class without restart Tomcat, but
they're usually pretty simple and locked down fairly early in the design
process to where this is usually not a problem.

If the amount of info is small, it can all be stored in a cookie or on the
URL.

If it's simply a single sign-on token, then a cookie would be your best bet.

The biggest detail with the session management is cleaning up afterwards.
You'll need some mechanism that dumps the sessions after they have expired.
This is something that comes "free" with the built-in session management,
but, of course, only works for a single webapp.

If you're persisting the session info to a DB, then you'll need some kind of
process that sweeps through the sessions and deletes the expired ones.
There's no reason to get overly complicated about it, it can easily be
integrated in the routine that creates a session for a new connection. You
can either just go brute force and delete all of the session info for
expired sessions every time (this will cost roudtrips to the DB, but odds
are pretty good they won't be doing much when they get there), or you can
use a singleton base counter and run the sweep, say, every 100 connections,
or whatever.

Or you can give a rip, "disk is cheap", and run a simple process once a
hour/day/week/month. All depends on your load.

For an in memory singleton based manager, you could basically throw all of
the sessions onto a FIFO queue. Everytime the session is accessed, it gets
moved back to the head of the queue. Then, your periodic sweeper can simply
start at the tail of the queue (all of the oldest sessions) and compare
timestamps until you've reached your time out limit. All of those sessions
that have expired are tossed aside for the GC to deal with.

Regards,

Will Hartung
(willh@msoft.com)

----- Original Message -----
From: "Andy Eastham" <an...@gliant.com>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Monday, July 08, 2002 8:20 AM
Subject: RE: Feasibility question


> Iain,
>
> By "off the shelf sessions", I mean the ones you are already using  when
you
> don't need to share them across webapps (ie created by the servlet
container
> by request.getSession(true)).
>
> Sorry for the confusion.
>
> Andy
>
> > -----Original Message-----
> > From: Iain Downie [mailto:iain.downie@bto.org]
> > Sent: 08 July 2002 16:02
> > To: Tomcat Users List
> > Subject: Re: Feasibility question
> >
> >
> > Andy,
> >
> > > Of course, non of these are as easy or efficient as the off the shelf
> > > sessions, but all are valid ways of achieving what you want.
> >
> > if you can spare a minute, can you be more specific about these 'off the
> > shelf' sessions?
> >
> > Thanks
> > Iain
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Feasibility question

[Andy Eastham <an...@gliant.com>]

Iain,

By "off the shelf sessions", I mean the ones you are already using  when you
don't need to share them across webapps (ie created by the servlet container
by request.getSession(true)).

Sorry for the confusion.

Andy

> -----Original Message-----
> From: Iain Downie [mailto:iain.downie@bto.org]
> Sent: 08 July 2002 16:02
> To: Tomcat Users List
> Subject: Re: Feasibility question
>
>
> Andy,
>
> > Of course, non of these are as easy or efficient as the off the shelf
> > sessions, but all are valid ways of achieving what you want.
>
> if you can spare a minute, can you be more specific about these 'off the
> shelf' sessions?
>
> Thanks
> Iain
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Feasibility question

[Iain Downie <ia...@bto.org>]

Andy,

> Of course, non of these are as easy or efficient as the off the shelf
> sessions, but all are valid ways of achieving what you want.

if you can spare a minute, can you be more specific about these 'off the
shelf' sessions?

Thanks
Iain


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Feasibility question

[Andy Eastham <an...@gliant.com>]

Iain,

I don't think session sharing is easy, but you can implement login using
cookies, which will be shared if they come from the same server (or domain
if they are domain cookies).

Another alternative is to pass a session id in the URL, and store session
information yourself in a server persistent object.  If you write a
singleton class and put it in a jar under Tomcat/common/lib, instances will
be shared between webapps (on Tomcat Version 4.0.3 anyway).

Of course, you can also write session information to a database.  When a
user logs in, generate a unique key, write this into a "Logins" table as the
primary key, plus other information like time of login, time of last access
etc. When you get a request, check the cookie id against this table to see
if the user is logged in and their session hasn't expired.  If so, update
the time of last access.

Of course, non of these are as easy or efficient as the off the shelf
sessions, but all are valid ways of achieving what you want.

All the best,

Andy

> -----Original Message-----
> From: Iain Downie [mailto:iain.downie@bto.org]
> Sent: 08 July 2002 15:12
> To: tomcat-user@jakarta.apache.org
> Subject: Feasibility question
>
>
> Hi List,
>
> relatively new to Tomcat, so excuse the possible repetition / naivety of
> this posting. We currently have an expanding web application
> running. We are
> thinking of dividing it up into more user-friendly chunks (different
> applications), allowing us to control each application more
> easily (stop one
> without affecting others etc.). My question is, is it possible to pass
> session info between many different applications?
>
> For example, these are our surveys, which we want as different apps.
> 1. Login and generic registration
> 2. Spring birdwatch
> 3. Garden birdwatch
> 4. Other survey and so on.
> They will all be attached to one Oracle installation.
>
> Currently, 1 and 2 are combined, so no problem with session info.
> But is it
> possible to transfer the user details between these apps, so that someone
> who is in Spring, can move over to Garden without having to login again?
>
> I'm not looking for the solution (for now), just to know if it is possible
> or not.
>
> Thanks, hope someone can suggest some pointers
> Iain
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>