Am 23.10.2014 um 19:45 schrieb spr...@gmx.eu:
You may want to have a look at parallel deployment (
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html).
At the moment /Catalina/localhost/ is used as value in column app. It
is the
root app.
Would a war ROOT##2.war use another value?
No
> Well, I think it solves your problem. Old session-ids will
> get routed to
> the old version of your webapp and thus will be deserialized
> without a
> problem. New sessions will be created in the new version.
Yes, but the session persistence will go into the same table rows -> chrash
while
Am 23.10.2014 um 19:45 schrieb spr...@gmx.eu:
You may want to have a look at parallel deployment (
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html).
At the moment /Catalina/localhost/ is used as value in column app. It
is the
root app.
Would a war ROOT##2.war use another value?
No
> >> You may want to have a look at parallel deployment (
> >> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html).
> >
> >
> >At the moment /Catalina/localhost/ is used as value in column app. It
> >is the
> >root app.
> >
> >Would a war ROOT##2.war use another value?
> No.
OK, then t
Am 23. Oktober 2014 13:34:22 MESZ, schrieb spr...@gmx.eu:
>> You may want to have a look at parallel deployment (
>> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html).
>
>
>At the moment /Catalina/localhost/ is used as value in column app. It
>is the
>root app.
>
>Would a war ROOT##2.
> Are you using distributed sessions? If so, you'll have to override the
> internal serialization mechanism and do it all manually in a way that
> is going to be cross-version-compatible.
>
> It's not impossible, but it does take some planning and forethought.
OK; thought so.
Thank you.
---
> You may want to have a look at parallel deployment (
> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html).
At the moment /Catalina/localhost/ is used as value in column app. It is the
root app.
Would a war ROOT##2.war use another value?
Am 22. Oktober 2014 21:20:12 MESZ, schrieb spr...@gmx.eu:
>Hi,
>
>when I deploy a new app version with incompatible serialization version
>of
>same classes I get:
>
>java.io.InvalidClassException:
>org.hibernate.collection.internal.AbstractPersistentCollection; local
...
>
>Is there something in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
To whom it may concern,
On 10/22/14 3:20 PM, spr...@gmx.eu wrote:
> when I deploy a new app version with incompatible serialization
> version of same classes I get:
>
> java.io.InvalidClassException:
> org.hibernate.collection.internal.AbstractPer
Badh, Tajvinder [mailto:tajvinder.b...@emc.com]
> Sent: 27 April 2011 11:19
> To: Reinwald Warapen; Tomcat Users List
> Subject: RE: JDBCStore Persistent Manager
>
> Hi,
>
> Thank you for the suggestions. I will take try it out and let you know how it
> goe
would need to be entered into this section
of the configuration?
Regards,
Taj
-Original Message-
From: Badh, Tajvinder [mailto:tajvinder.b...@emc.com]
Sent: 27 April 2011 11:19
To: Reinwald Warapen; Tomcat Users List
Subject: RE: JDBCStore Persistent Manager
Hi,
Thank you for the
Hi,
Thank you for the suggestions. I will take try it out and let you know how it
goes.
Regards,
Taj
-Original Message-
From: Reinwald Warapen [mailto:reinwal...@directi.com]
Sent: 27 April 2011 10:18
To: Tomcat Users List
Cc: Badh, Tajvinder
Subject: Re: JDBCStore Persistent Manager
I had the same requirement and tried everything possible with the
Persistent Manager. I use the Memcached Session Manager (non-sticky
approach) and it works brilliantly.
Take a look at this which may be of help to you :
http://www.reinwaldwarapen.com/2011/01/storing-and-sharing-sessions-among.
An option for such a case is memcached-session-manager with stickyness
disabled: http://code.google.com/p/memcached-session-manager/
A user reported on the msm mailing list that he was trying to achieve the
same what you want, also with persistentmanager, but ran into the same
problem as you do. T
14 matches
Mail list logo
