Hopbot log for 2008-01-31 - Helma IRC channel: #helma on irc.freenode.net

2008-01-31:

[17:29] <pek> Hey guys. One question: Is it possible to persist session data to db or memcached in helma? I need true failover with no sticky sessions, så I have to store session data in a way that every app-server can have access to it.
[17:31] <pek> If not (out of the box) I have to create something myself, but I couldn't find a serialize(object) to string, only to file. That makes it a little trickier I think.
[18:00] <zumbrunn> pek, I take it you know about the persistentSessions app/server property but that's not "true failover" enough for you?
[18:01] <pek> As i understand it, 'persistentSessions' persists objects in the "internal" database, right?
[18:01] <zumbrunn> no, in a separate file
[18:02] <zumbrunn> but it does so when helma or the app is shutdown/stopped/quit
[18:02] <pek> ok, but to file on the same appserver. so I would need to persist to NFS to make it available for more than one server
[18:02] <zumbrunn> if there is a power failure that wouldn't help, I believe
[18:02] <pek> what i need is to have my session data available to all my appservers at the same time
[18:02] <pek> if one server goes down, the user won't be logged out
[18:03] <zumbrunn> I'm not aware of anything built-in that would allow sessions persisted in the db
[18:03] <zumbrunn> but you might want to ask about that on the helma-user mailing list
[18:03] <pek> it's quite easy to make a sessionfacade for my usage, I just need to find serialze(obj) => string
[18:04] <pek> its in the rhino framework, but I've only found to file/binary in helma, and that would be a little slow....
[18:04] <pek> but I'll keep on diging
[18:04] <pek> brb... my dog is not happy right now ;)
[18:09] <zumbrunn> you're not talking about just different helma instances, right?
[18:10] <zumbrunn> otherwise helmaswarm would do the trick
[18:10] <zumbrunn> http://dev.helma.org/wiki/HelmaSwarm/
[18:34] <pek> Yes I saw swarm, but it seemed like a bit overkill for my use right now. But it looked kinda cool
[18:35] <pek> but it's async, and not quite "safe" to run w/o sticky sessions.
[18:41] <hypersmil> pek: you can run into serious trouble when accessing the same db from two helma instances without helmaswarm - esp. id generation and object cache
[18:43] <pek> yes, I understand that. I wasn't trying to change the underlying object cache, just to have a central storage for session data. What I'm trying to do is to have true failover so that users don't get logged out if one of the servers in the cluster goes down.
[18:44] <pek> and that, in reality, is to bypass the whole session logic in helma itself and go homebrew.
[18:44] <pek> I think...
[18:48] <hypersmil> maybe use helmaswarm without id generator & swarmcache :)
[22:55] <pek> am I wrong, or isn't helma doing any joins, just lookup by id/primary keys? Looks that way in my logs, but I haven't played around with the different collection settings in type.properties (yet)

 

 

In the channel now:

Logs by date: