Application Server Solutions for Microsoft IIS and ASP.NET
       solutions   products   partners   company   support   downloads         store
View Interest List Message Details
<< Back to Search Results

Date: 05/17/2006
From: matt@newatlanta.com
Subject: Re: [ServletExec] Problem in using JDBC Sesion Manager
One other thing... consider sharing your modified queries on this list 
so that others using Oracle 8i can benefit should they decide to use the 
JdbcSessionManager also.

:-)

Matt McGinty
Software Engineer
New Atlanta Communications, LLC
http://www.newatlanta.com 



matt@newatlanta.com wrote:

> Rashmi,
>
> Yes, I'd say it should be fine to use
>
>apply.oracle.gmt.offset=false
>
>since it would appear that there is no offset to apply in your case (Oracle 
8i).
>
>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          
applications.
>You said:
>"Identical copies of the application is deployed on each of the 5      
servers."
>
>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      
discussion.
>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.
>
>
>And remember:
>
>The main requirement is that your dbms must support Row-Level locking,
>and the following 3 named queries:
>
>"select.existing.session"
>
>"select.existing.session.ids.to.delete"
>
>-and-
>
>"select.existing.session.for.cleanup"
>
>
>must use a syntax that causes the selected row(s) to be locked.
>
>  
>
>Matt McGinty
>Software Engineer
>New Atlanta Communications, LLC
>http://www.newatlanta.com 
>
>
>
> Rashmi Kumari wrote:
>
>>Hi Matt,
>>
>>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 the

>>same webserver.
>>Here I just wanted to clarify that our application is
>>hosted on 5 SE AS instances running behind 5 different instances of
>>IPlanet.
>>Identical copies of the application is deployed on each of the 5        
servers.
>>when external user hits the application URL, he is directed to the IP   
of
>>the
>>load balancer which  forwards request to any of the above servers and
>>maintains
>>a sticky session with that server so  that every consequent request     
from
>>same IP
>>is directed to the same server for that session. But this architecture
>>fails for
>>AOL users as their IP change dynamically. So the session data cannot be

>>maintained
>>for a particular user.
>>
>>This is the reason why we are exploring session clustering . So, will   
this
>>architecture be suitable for
>>the clustering.  Do we have to replicate jdbcSessionManger.properties   
file
>>also on all the five servers.
>>
>>Regards,
>>
>>Rashmi
>>
>>
>>
>>
>>
>>------------------------------------------------------------------------
-
>>ServletExec-Interest. For archives and unsubscribe instructions, visit:

>>
>>    http://www.newatlanta.com/servletexec-interest.jsp
>>  
>>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
 <meta content="text/html;charset=ISO-8859-1"                      
http-equiv="Content-Type">
 <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Verdana">One other thing... consider sharing your   
modified
queries on this list so that others using Oracle 8i can benefit should
they decide to use the JdbcSessionManager also.<br>
<br>
<span class="moz-smiley-s1"><span> :-)                    
</span></span><br>
</font>
<pre class="moz-signature" cols="72">Matt McGinty
Software Engineer
New Atlanta Communications, LLC
<a class="moz-txt-link-freetext"                                   
href="http://www.newatlanta.com">http://www.newatlanta.com</a>
; </pre>
<br>
<br>
<a class="moz-txt-link-abbreviated"                                
href="mailto:matt@newatlanta.com">matt@newatlanta.com</a>    
wrote:
<blockquote cite="mid446B2D52.9080400@newatlanta.com"              
type="cite">
 <meta content="text/html;charset=ISO-8859-1"                      
http-equiv="Content-Type">
 <font face="Verdana">Rashmi,<br>
 <br>
Yes, I'd say it should be fine to use<br>
 </font>
 <pre wrap="">apply.oracle.gmt.offset=false

since it would appear that there is no offset to apply in your case (Oracle     
8i).

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              
applications.
You said:
"Identical copies of the application is deployed on each of the 5          
servers."

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          
discussion.
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.


And remember:
<font face="Verdana">
The main requirement is that your dbms must support Row-Level locking,
and the following 3 named queries:

"select.existing.session"

"select.existing.session.ids.to.delete"

-and-

"select.existing.session.for.cleanup"


must use a syntax that causes the selected row(s) to be locked.</font>

 </pre>
 <pre class="moz-signature" cols="72">Matt McGinty
Software Engineer
New Atlanta Communications, LLC
<a class="moz-txt-link-freetext"                                   
href="http://www.newatlanta.com">http://www.newatlanta.com</a>
; </pre>
 <br>
 <br>
Rashmi Kumari wrote:
 <blockquote
cite="midOF157BD6EB.F940CF09-ON65257171.002F9589-6
5257171.00326B81@rmsi.com"
type="cite">
   <pre wrap="">Hi Matt,

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 the
same webserver.
Here I just wanted to clarify that our application is
hosted on 5 SE AS instances running behind 5 different instances of
IPlanet.
Identical copies of the application is deployed on each of the 5 servers.
when external user hits the application URL, he is directed to the IP of
the
load balancer which  forwards request to any of the above servers and
maintains
a sticky session with that server so  that every consequent request from
same IP
is directed to the same server for that session. But this architecture
fails for
AOL users as their IP change dynamically. So the session data cannot be
maintained
for a particular user.

This is the reason why we are exploring session clustering . So, will this
architecture be suitable for
the clustering.  Do we have to replicate jdbcSessionManger.properties file
also on all the five servers.

Regards,

Rashmi





-------------------------------------------------------------------------
ServletExec-Interest. For archives and unsubscribe instructions, visit:

   <a class="moz-txt-link-freetext"
href="http://www.newatlanta.com/servletexec-i
nterest.jsp">http://www.newatlanta.com/servletexec-i
nterest.jsp</a>
 </pre>
 </blockquote>
</blockquote>
</body>
</html>

Message Thread
Date Subject Author
05/17/2006 Re: [ServletExec] Problem in using JDBC Sesion Manager matt@newatlanta.com
05/17/2006 Re: [ServletExec] Problem in using JDBC Sesion Manager matt@newatlanta.com
05/18/2006 Re: [ServletExec] Problem in using JDBC Sesion Manager Rashmi.Kumari@rmsi.com
05/17/2006 [ServletExec] Problem in using JDBC Sesion Manager Rashmi.Kumari@rmsi.com
<< Back to Search Results


   
company media information terms of use privacy policy contact us