Thanks a lot for your detailed replies.
We are going to work on this session clustering in our application.
Regarding sharing of queries modified for Oracle 8i, I am glad to do so
that users using Oracle 8i may benefit.
Here are the queries customized to work on Oracle 8i database:
create.session.table.1=create table shared_sessions (session_id char(27)
NOT NULL primary key, creation_time date NOT NULL,
current_accessed_time date NOT NULL, session_timeout number NOT NULL,
session_object blob NOT NULL)
select.current.time.3=select to_char(sysdate, 'mm/dd/yyyy hh:mi:ss
select.current.time.4=select to_char(sysdate, 'mm/dd/yyyy hh:mi:ss
select.current.time.5=select to_char(sysdate, 'mm/dd/yyyy hh:mi:ss
insert.new.session.1=insert into shared_sessions (session_id,
session_timeout, session_object, creation_time, current_accessed_time)
values (?, ?, ?, TO_Date( TO_char( sysdate, 'MM/DD/YYYY HH:MI:SS
'MM/DD/YYYY HH:MI:SS AM'),TO_Date( TO_char( sysdate, 'MM/DD/YYYY
AM'), 'MM/DD/YYYY HH:MI:SS AM'))
update.existing.session.current.accessed.1=update shared_sessions set
current_accessed_time=(select to_char(sysdate, 'mm/dd/yyyy hh:mi:ss
from dual) where rtrim(session_id) = ?
select.existing.session.1=select current_accessed_time, session_object from
shared_sessions where session_id = ? for update
update.existing.session.1=update shared_sessions set session_object = ?,
session_timeout = ? where session_id = ?
delete.existing.session.1=delete from shared_sessions where session_id = ?
update.existing.session.timed.out.1=update shared_sessions set
session_timeout = 0 where session_timeout > 0 AND session_id IN (select
session_id from shared_sessions where current_accessed_time +
session_timeout/86400 <= (select current_accessed_time from shared_sessions
where rtrim(session_id) = ?))
select.existing.session.ids.to.delete.1=select session_id from
shared_sessions where session_timeout = 0 for update
select.existing.session.for.cleanup.1=select session_object from
shared_sessions where session_id = ? for update
select.existing.session.ids.1=select session_id from shared_sessions
select.num.current.active.1=select count(*) from shared_sessions
I will let you know if everything works fine when we configure on live.
Sent by: To:
tlanta.com Subject: Re:
[ServletExec] Problem in using JDBC Sesion Manager
05/17/2006 07:34 PM
Please respond to
Yes, I'd say it should be fine to use
since it would appear that there is no offset to apply in your case (Oracle
Your architecture sounds fine.
The JdbcSessionManager will solve this problem for you, and allow
non-sticky load balancing.
Yes you'll need to replicate the properties file on all the 5
"Identical copies of the application is deployed on each of the 5
Each app needs to have it's own private copy of that properties file
(inside WEB-INF\classes\com\newatlanta\servletexec\session\ )
and each of those 5 files should be identical to each other.
You'll also need to configure the datasource the same inside each of the 5
SE AS Instances.
The reason I used the example that I did was because it simplified the
The hostname for the various requests would need to be the same else the
browser won't send the session id cookie.
Using a single webserver is one way to ensure (usually) that the hostname
is the same for all requests.
Using a load balancer in front of a "farm" of webserver is obviously
another way to do that.
The main requirement is that your dbms must support Row-Level locking,
and the following 3 named queries:
must use a syntax that causes the selected row(s) to be locked.
New Atlanta Communications, LLC
Rashmi Kumari wrote:
Thanks for the reply.
I executed "select sessiontimezone from dual" in SQL *Plus.
The result returnesd was +00.00.
Same query using JDBC code returned +00.00.
So now is it ok to use
apply.oracle.gmt.offset=false in jdbcSessionManger.properties file.
Also you had written to test using 2 SE AS instances running behind
Here I just wanted to clarify that our application is
hosted on 5 SE AS instances running behind 5 different instances of
Identical copies of the application is deployed on each of the 5
when external user hits the application URL, he is directed to the IP
load balancer which forwards request to any of the above servers and
a sticky session with that server so that every consequent request
is directed to the same server for that session. But this architecture
AOL users as their IP change dynamically. So the session data cannot
for a particular user.
This is the reason why we are exploring session clustering . So, will
architecture be suitable for
the clustering. Do we have to replicate jdbcSessionManger.properties
also on all the five servers.
ServletExec-Interest. For archives and unsubscribe instructions,
ServletExec-Interest. For archives and unsubscribe instructions, visit: