Re: hot redeployment - how to preserve session state?

2002-01-30 Thread Peter Beck

I tried to use the hot-deploy just for development to not always have to 
restart Orion and log in.
To only have to restart the server when classes change which are stored 
in the session would be better than on every little change during bug 
fixing...

On this list I read about people using this, and the problem they were 
talking about most of the time was that classes have to be serializable...
Now I tried that with a few objects in the session, and all of them were 
lost after touching application.xml.

Peter

Aaron Tavistock wrote:

I'm not currently doing hot-deploy, but I've always wonder how it could
posibly work given that a serialized class might have the underlying base
class changed during hot-deploy (e.g. the classic 'run instance' is
different than a 'new instance' problem that java throws a
ClassCastException from).  Its also theoretically problematic (I'm not sure
if instanceof or reflection will work properly).

Since this is a very low-level issue (e.g. Java simply doesn't have the
facilities to really handle this), how does hot-deply work?  The only
reliable strategy would appear to be to preserver primatives (since they
don't change), maybe preserve 'well-defined' objects (java.util.* is
unlikely to change), and discard all the rest.

Any thoughts? 

AT

-Original Message-
From: Peter Beck [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 29, 2002 7:41 AM
To: Orion-Interest
Subject: hot redeployment - how to preserve session state?


After a forced redeployment of an application on Orion 1.5.3 by touching 
application.xml
my session state seemst to be completely lost.

I have set development=true in my global-web-application.xml, and the 
switch is present in the orion-web.xml in the application- deployment 
directory.
The variables I try to serialize implement the Serializable interface. 
Some of them are simple JavaBeans, others just Strings.

For testing I use a JSP which prints the variables in the session. 
Before the redeployment everything is there.
and when a user is logged in, request.getRemoteUser() gives me the 
correct user name.
After the redeployment session.toString() still gives me the same ID as 
before, but all variables in the session are gone.
Even request.getRemoteUser() == null.

What am I missing?

Peter

-- 
Peter Beck, JOANNEUM RESEARCH Forschungsges.m.b.H.
[EMAIL PROTECTED]







Re: hot redeployment - how to preserve session state?

2002-01-30 Thread Daniel López

Hi Peter,
We use hot-deployment in production, to be able to update the 
application without losing all the sessions. But you have to configure 
Orion explicitly to keep the session state, as it is disabled by 
default. On the other hand, we also us it during development, but if you 
update the ear file very often, you usually ends up complaining with an 
OutOfMemoryException or some sort of decompression problems. So it is 
not very stable when used very often in a short period of time. That's 
why we try no to hot-deploy the ears in production very often, as it 
might cause a kaa-boum.
I hope it helps,
D.

Peter Beck wrote:

 I tried to use the hot-deploy just for development to not always have to 
 restart Orion and log in.
 To only have to restart the server when classes change which are stored 
 in the session would be better than on every little change during bug 
 fixing...
 
 On this list I read about people using this, and the problem they were 
 talking about most of the time was that classes have to be serializable...
 Now I tried that with a few objects in the session, and all of them were 
 lost after touching application.xml.
 
 Peter
 
 Aaron Tavistock wrote:
 
 I'm not currently doing hot-deploy, but I've always wonder how it could
 posibly work given that a serialized class might have the underlying base
 class changed during hot-deploy (e.g. the classic 'run instance' is
 different than a 'new instance' problem that java throws a
 ClassCastException from).  Its also theoretically problematic (I'm not 
 sure
 if instanceof or reflection will work properly).

 Since this is a very low-level issue (e.g. Java simply doesn't have the
 facilities to really handle this), how does hot-deply work?  The only
 reliable strategy would appear to be to preserver primatives (since they
 don't change), maybe preserve 'well-defined' objects (java.util.* is
 unlikely to change), and discard all the rest.

 Any thoughts?
 AT

 -Original Message-
 From: Peter Beck [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, January 29, 2002 7:41 AM
 To: Orion-Interest
 Subject: hot redeployment - how to preserve session state?


 After a forced redeployment of an application on Orion 1.5.3 by 
 touching application.xml
 my session state seemst to be completely lost.

 I have set development=true in my global-web-application.xml, and the 
 switch is present in the orion-web.xml in the application- deployment 
 directory.
 The variables I try to serialize implement the Serializable interface. 
 Some of them are simple JavaBeans, others just Strings.

 For testing I use a JSP which prints the variables in the session. 
 Before the redeployment everything is there.
 and when a user is logged in, request.getRemoteUser() gives me the 
 correct user name.
 After the redeployment session.toString() still gives me the same ID 
 as before, but all variables in the session are gone.
 Even request.getRemoteUser() == null.

 What am I missing?

 Peter






Re: hot redeployment - how to preserve session state?

2002-01-30 Thread Jose Mena



Hi you all,
i have a question. I have an oracle data-source 
configured on a 1.5.2 orion server. Here you are:
data-sourcesdata-source 
class="com.evermind.sql.DriverManagerDataSource" 
name="IMS" 
location="jdbc/IMSCoreDS" 
xa-location="jdbc/xa/IMSXADS" 
ejb-location="jdbc/IMSDS" 
schema="database-schemas/oracle.xml" 
connection-driver="oracle.jdbc.driver.OracleDriver" 
username="user" 
password="password" 
url="jdbc:oracle:thin:@10.3.1.6:port:SID" 
inactivity-timeout="30" 
//data-sources
It works fine. But the problem comes when i have a 
network problem to connect to the data-base. Then orion isn't able to make a 
connection and instead of giving up connecting after 3 attemps(as i read this is 
the default value for the max-connect-attempts) itgetshanged up 
trying toconnect. is there any way to tell orion a connection 
timeoutfor oracle connections?
Thank u.
- Original Message - 
From: "Daniel López" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Wednesday, January 30, 2002 1:10 
PM
Subject: Re: hot redeployment - how to preserve 
session state?
 Hi Peter, We use hot-deployment in production, to be able to 
update the  application without losing all the sessions. But you have to 
configure  Orion explicitly to keep the session state, as it is disabled 
by  default. On the other hand, we also us it during development, but if 
you  update the ear file very often, you usually ends up complaining 
with an  OutOfMemoryException or some sort of decompression problems. So 
it is  not very stable when used very often in a short period of time. 
That's  why we try no to hot-deploy the ears in production very often, 
as it  might cause a kaa-boum. I hope it helps, 
D.  Peter Beck wrote:   I tried to use the 
hot-deploy just for development to not always have to   restart 
Orion and log in.  To only have to restart the server when classes 
change which are stored   in the session would be better than on 
every little change during bug   fixing...   
 On this list I read about people using this, and the problem they were 
  talking about most of the time was that classes have to be 
serializable...  Now I tried that with a few objects in the session, 
and all of them were   lost after touching application.xml. 
   PeterAaron Tavistock 
wrote:I'm not currently doing hot-deploy, but 
I've always wonder how it could  posibly work given that a 
serialized class might have the underlying base  class changed 
during hot-deploy (e.g. the classic 'run instance' is  different 
than a 'new instance' problem that java throws a  
ClassCastException from). Its also theoretically problematic (I'm not 
  sure  if instanceof or reflection will work 
properly).   Since this is a very low-level 
issue (e.g. Java simply doesn't have the  facilities to really 
handle this), how does hot-deply work? The only  reliable 
strategy would appear to be to preserver primatives (since they  
don't change), maybe preserve 'well-defined' objects (java.util.* is 
 unlikely to change), and discard all the rest.  
 Any thoughts?  AT   
-Original Message-  From: Peter Beck 
[mailto:[EMAIL PROTECTED]]  Sent: Tuesday, January 29, 
2002 7:41 AM  To: Orion-Interest  Subject: hot 
redeployment - how to preserve session state?  
  After a forced redeployment of an application on Orion 
1.5.3 by   touching application.xml  my session 
state seemst to be completely lost.   I have set 
development=true in my global-web-application.xml, and the   
switch is present in the orion-web.xml in the application- deployment  
 directory.  The variables I try to serialize implement 
the Serializable interface.   Some of them are simple JavaBeans, 
others just Strings.   For testing I use a JSP 
which prints the variables in the session.   Before the 
redeployment everything is there.  and when a user is logged in, 
request.getRemoteUser() gives me the   correct user 
name.  After the redeployment session.toString() still gives me 
the same ID   as before, but all variables in the session are 
gone.  Even request.getRemoteUser() == null. 
  What am I missing?   
Peter   


RE: hot redeployment - how to preserve session state?

2002-01-29 Thread Aaron Tavistock

I'm not currently doing hot-deploy, but I've always wonder how it could
posibly work given that a serialized class might have the underlying base
class changed during hot-deploy (e.g. the classic 'run instance' is
different than a 'new instance' problem that java throws a
ClassCastException from).  Its also theoretically problematic (I'm not sure
if instanceof or reflection will work properly).

Since this is a very low-level issue (e.g. Java simply doesn't have the
facilities to really handle this), how does hot-deply work?  The only
reliable strategy would appear to be to preserver primatives (since they
don't change), maybe preserve 'well-defined' objects (java.util.* is
unlikely to change), and discard all the rest.

Any thoughts? 

AT

-Original Message-
From: Peter Beck [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 29, 2002 7:41 AM
To: Orion-Interest
Subject: hot redeployment - how to preserve session state?


After a forced redeployment of an application on Orion 1.5.3 by touching 
application.xml
my session state seemst to be completely lost.

I have set development=true in my global-web-application.xml, and the 
switch is present in the orion-web.xml in the application- deployment 
directory.
The variables I try to serialize implement the Serializable interface. 
Some of them are simple JavaBeans, others just Strings.

For testing I use a JSP which prints the variables in the session. 
Before the redeployment everything is there.
and when a user is logged in, request.getRemoteUser() gives me the 
correct user name.
After the redeployment session.toString() still gives me the same ID as 
before, but all variables in the session are gone.
Even request.getRemoteUser() == null.

What am I missing?

Peter






Re: hot redeployment - how to preserve session state?

2002-01-29 Thread Daniel López

Hi Aaron,

We preserve session state through hot and cold deploys with no problem, 
unless you explicitly change the objects involved in keeping the session 
state, or any object that is stored in the context. However, it is not 
impossible to modify these objects while preserving your state, as long 
as you know how to handle serialisation issues. If you are careful with 
the classes you put in sessions and the context ( make them serializable 
and take into account the possible evolution of classes ) then you will 
minimize your problems.
Have a look at the Object Serialization part of the Java SDK 
Documentation to learn more about that.

BTW: The attribute to get persistence to work in Orion is not 
development=true but persistence-path=../temp/persistence.ser. So your 
  global-web-application.xml should look something like...
orion-web-app
 ...
persistence-path=../temp/persistence.ser
 ...
 
...

I hope it helps,
D.

Aaron Tavistock wrote:

 I'm not currently doing hot-deploy, but I've always wonder how it could
 posibly work given that a serialized class might have the underlying base
 class changed during hot-deploy (e.g. the classic 'run instance' is
 different than a 'new instance' problem that java throws a
 ClassCastException from).  Its also theoretically problematic (I'm not sure
 if instanceof or reflection will work properly).
 
 Since this is a very low-level issue (e.g. Java simply doesn't have the
 facilities to really handle this), how does hot-deply work?  The only
 reliable strategy would appear to be to preserver primatives (since they
 don't change), maybe preserve 'well-defined' objects (java.util.* is
 unlikely to change), and discard all the rest.
 
 Any thoughts? 
 
 AT
 
 -Original Message-
 From: Peter Beck [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, January 29, 2002 7:41 AM
 To: Orion-Interest
 Subject: hot redeployment - how to preserve session state?
 
 
 After a forced redeployment of an application on Orion 1.5.3 by touching 
 application.xml
 my session state seemst to be completely lost.
 
 I have set development=true in my global-web-application.xml, and the 
 switch is present in the orion-web.xml in the application- deployment 
 directory.
 The variables I try to serialize implement the Serializable interface. 
 Some of them are simple JavaBeans, others just Strings.
 
 For testing I use a JSP which prints the variables in the session. 
 Before the redeployment everything is there.
 and when a user is logged in, request.getRemoteUser() gives me the 
 correct user name.
 After the redeployment session.toString() still gives me the same ID as 
 before, but all variables in the session are gone.
 Even request.getRemoteUser() == null.
 
 What am I missing?
 
 Peter