Yes indeed this is not something officially supported. That said, I
take this opportunity to commend your effort and persistence in getting
this to work.
Very much appreciated and is in the great spirit of community we have
around GlassFish.
It would be great to get more testing data around this to see how viable
this approach is - so if anyone has more data to offer on this, that
would be great.
Thanks again
Shreedhar
glassfish_at_javadesktop.org wrote:
> OK, I think I have it working with oracle - although I'm sure it's not officially supported. Here's what I did. I created a local cluster of 2 instances (I don't think you need to do this, but it made testing a bit easier).
>
> In the admin, the application needs to have the Availability enabled (by default it is not).
>
> The session sun-web.xml descriptor for the WAR needs to look something like (notice the 'ha' type for persistence-type:
>
> <session-config>
> <session-manager persistence-type="ha">
> <manager-properties>
> <property name="persistenceFrequency" value="web-method"/>
> </manager-properties>
> <store-properties>
> </store-properties>
> </session-manager>
> <session-properties/>
> <cookie-properties/>
> </session-config>
>
>
> Here's where I kinda mucked around a bit. The server appeared to be trying to find a DataSource "jdbc/hastore__pm". Now the '__pm' suffix I think is used internally by Sun. In any event, I created a datasource with the afforementioned JNDI name, and mapped that to my Oracle connection pool. The code is expecting the following table structure in that database - so here's the DDL script for that table that I came up with (note, the actual PK probably should be the ID and APPID since it's possbile 2 web applications COULD produce the same session id:
>
> create table blobSessions
> (
> ID varchar2(512) primary key,
> SESSDATA BLOB,
> USERNAME VARCHAR2(512),
> SSOID VARCHAR2(512),
> APPID varchar2(512),
> LASTACCESS number(20),
> VALID varchar2(1),
> MAXINACTIVE number(20)
> )
>
> I then stored a hashmap of junk in the session and read it out. It worked in my one instance. I then stopped that instance, and was able to read the session info out from the other instance. So at least it appears to work. Since this is probably not the 'official' way of doing it, there may be some unintended consequences. Please advise if anyone has done something other to get this to work.
>
> Cheers!
> [Message sent by forum member 'csiemback' (csiemback)]
>
> http://forums.java.net/jive/thread.jspa?messageID=338969
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>