On Jul 9, 2008, at 11:57 AM, Scott Ferguson wrote:
On Jul 9, 2008, at 8:07 AM, Bernard Bernstein wrote:
Running Resin 3.0.21
Another thought is if there is some way to use a Persistent Store
with always-load-session and always-save-session set, so that the
cluster members don't need to know each other, but rather just
handle their sessions through the database with no interaction with
each other. Perhaps even better yet, they could store these
sessions through a memcached instance which can save/restore using
a database but provide memory-based access to the session store.
The jdbc-store would do the first. The instances do still need to
know about each other to get the index/cookie generation right, but
otherwise they wouldn't need to know about each other.
-- Scott
I just did a quick test of two instances set to use the same jdbc
persistent-store and I did not set them up to know about each other in
the <cluster> config. They were configured as if they were each alone
in the cluster, but set to use the same store.
Can you explain what problems I might expect to see by using a shared
store without the cluster members communicating with each other?
Here are the relevant config excerpts:
<http id="" port="${hport}"/>
<cluster>
<srun id="" port="${sport}" />
</cluster>
<database jndi-name="jdbc/resin_session">
<driver type="com.mysql.jdbc.Driver">
<url>jdbc:mysql://-my-database-</url>
<user>-user-</user>
<password>-pass-</password>
</driver>
</database>
<persistent-store type="jdbc">
<init>
<data-source>jdbc/resin_session</data-source>
</init>
</persistent-store>
<session-config>
<use-persistent-store/>
<always-save-session/>
<always-load-session/>
</session-config>
_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
