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-sources>
<data-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) it gets hanged up trying to connect. is there any way to tell orion a connection timeout for 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.
> >
> > 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
>
>
>

Reply via email to