Hi again people, I've just read the article about SESSIONS in the upcoming ZOPE Book 2.7. Here, we have ZEO running, and I need to use SESSION and ZEO. I read the article http://www.zope.org/Members/randy/ZEO-Sessions. Isn't there a easy way to do this? I was wondering if I couldn just createa new filestorage entry in the zeo.conf, and add some lines in my zope.conf file. Thanks. Fernando Lujan
Yes. All the information in that article is geared for Zope 2.5 which had no facility for using mounted databases from a config file... everything up until "At this time you should be able to navigate to the /session_storage folder..." in that article can be done by reconfiguring ZEO using zeo.conf to serve a new storage, changing your ZEO clients' zope.conf files to recognize the new storage and adding a "ZODB Mount Point" from within the ZMI from one of the appservers. The rest of it is pretty simple. ;-) - C
Chris McDonough wrote:
Yes.
All the information in that article is geared for Zope 2.5 which had no facility for using mounted databases from a config file... everything up until "At this time you should be able to navigate to the /session_storage folder..." in that article can be done by reconfiguring ZEO using zeo.conf to serve a new storage, changing your ZEO clients' zope.conf files to recognize the new storage and adding a "ZODB Mount Point" from within the ZMI from one of the appservers. The rest of it is pretty simple. ;-)
Please, take a look in what I've done! Is that right? It works pretty fine here! :-) If this is right, are there a desire for a how-to? I think I can write one, once it's pretty simple as you said. zope.conf <zodb_db main> mount-point /temp_folder container-class Products.TemporaryFolder.TemporaryContainer # ZODB cache, in number of objects cache-size 5000 <zeoclient> server localhost:8100 storage 1 name zeostorage var $INSTANCE/var # ZEO client cache, in bytes cache-size 20MB # Uncomment to have a persistent disk cache #client zeo1 </zeoclient> </zodb_db> <zodb_db temporary> mount-point / # ZODB cache, in number of objects cache-size 5000 <zeoclient> server localhost:8100 storage 2 name zeotemporary var $INSTANCE/var # ZEO client cache, in bytes cache-size 20MB # Uncomment to have a persistent disk cache #client zeo1 </zeoclient> </zodb_db> zeo.conf # ZEO configuration file %define INSTANCE /home/flujan/tmp/zeo <zeo> address 8100 read-only false invalidation-queue-size 100 # monitor-address PORT # transaction-timeout SECONDS </zeo> <filestorage 1> path $INSTANCE/var/Data.fs </filestorage> <filestorage 2> path $INSTANCE/var/SessionData.fs </filestorage> <eventlog> level info <logfile> path $INSTANCE/log/zeo.log </logfile> </eventlog> <runner> program $INSTANCE/bin/runzeo socket-name $INSTANCE/etc/zeo.zdsock daemon true forever false backoff-limit 10 exit-codes 0, 2 directory $INSTANCE default-to-interactive true # user zope python /usr/bin/python2.3 zdrun /usr/local/zope-2.7.5/lib/python/zdaemon/zdrun.py # This logfile should match the one in the zeo.conf file. # It is used by zdctl's logtail command, zdrun/zdctl doesn't write it. logfile $INSTANCE/log/zeo.log </runner>
On Tue, 2005-04-12 at 18:23, Fernando Lujan wrote:
Please, take a look in what I've done! Is that right? It works pretty fine here! :-)
If it works for you, it's right. ;-)
If this is right, are there a desire for a how-to? I think I can write one, once it's pretty simple as you said.
Sure, if you'd like... we could point to it from that chapter... - C
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 13 Apr 2005 05:47 am, Fernando Lujan wrote:
Isn't there a easy way to do this? I was wondering if I couldn just createa new filestorage entry in the zeo.conf, and add some lines in my zope.conf file.
Is there a viable non-versioned alternative to the filestorage approach? My sessions database grows ridiculously quickly. I'm also fairly sure it's causing problems when my site gets ~5 requests a second (yes, that low) Maybe one of these days I'll have time to look into SQLSession, but I'm not sure how well it will be able to replace the core session handling (and it does need to seamlessly replace it). I wonder how hard it'd be to write a new Session Data Manager using an RDBMS as the backend, or even just a filesystem approach that didn't use versioning. *shrug*. Mmm. Transactions. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCXFUJrGisBEHG6TARAphlAJ4hp/D6u0l/7G1MEhuEsLgykYASfACeNDm0 2CngEMS5lvja4vf2lSuCP5U= =+7Se -----END PGP SIGNATURE-----
On Tue, 2005-04-12 at 19:08, Richard Jones wrote:
Is there a viable non-versioned alternative to the filestorage approach? My sessions database grows ridiculously quickly. I'm also fairly sure it's causing problems when my site gets ~5 requests a second (yes, that low)
You could use temporarystorage on the ZEO server if you don't really need your session data to be persistent across ZEO server restarts. This is what Fernando appeared to do in the end. There are no well-maintained nonundoing storages that I know of other than temporarystorage. Once upon a time, BerkeleyStorage minimal used to work, but its gone the way of the dinosaurs apparently. I think any sessioning setup that uses a ZEO-backed storage will be more conflict-prone than one that doesn't use ZEO, just because the transaction commit time is typically longer. I'm not sure if this is the problem you mention.
Maybe one of these days I'll have time to look into SQLSession, but I'm not sure how well it will be able to replace the core session handling (and it does need to seamlessly replace it). I wonder how hard it'd be to write a new Session Data Manager using an RDBMS as the backend, or even just a filesystem approach that didn't use versioning. *shrug*. Mmm. Transactions.
Probably not hard. You could write a "session data manager" implementation that used a relational database. The interface for those things is in Products/Sessions/SessionInterfaces.py - C
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 13 Apr 2005 09:44 am, you wrote:
On Tue, 2005-04-12 at 19:08, Richard Jones wrote:
Is there a viable non-versioned alternative to the filestorage approach? My sessions database grows ridiculously quickly. I'm also fairly sure it's causing problems when my site gets ~5 requests a second (yes, that low)
You could use temporarystorage on the ZEO server if you don't really need your session data to be persistent across ZEO server restarts. This is what Fernando appeared to do in the end.
Having sessions persist across ZEO restarts is a handy thing. Also, I never figured how to configure a temp storage in a ZEO server. I started looking once, but either ran into a dead end or got distracted (or both ;)
There are no well-maintained nonundoing storages that I know of other than temporarystorage. Once upon a time, BerkeleyStorage minimal used to work, but its gone the way of the dinosaurs apparently.
And I distrust anything related to Berkely DB :)
I think any sessioning setup that uses a ZEO-backed storage will be more conflict-prone than one that doesn't use ZEO, just because the transaction commit time is typically longer. I'm not sure if this is the problem you mention.
Could be.
Probably not hard. You could write a "session data manager" implementation that used a relational database. The interface for those things is in Products/Sessions/SessionInterfaces.py
Yeah, I remember poking around that code way back, and it seemed reasonable. Its interactions with transactions are the bits that scare me. Using a standard RDBMS connection would probably solve that though. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCXGFkrGisBEHG6TARAkp7AJ9xavG5iY4wQjGLkdjGmvqxn/mDoACfRXsh 5vLa0EwojCSZlBAi7e1Vuqo= =WTon -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Jones wrote:
On Wed, 13 Apr 2005 09:44 am, Chris McDonough wrote:
Probably not hard. You could write a "session data manager" implementation that used a relational database. The interface for those things is in Products/Sessions/SessionInterfaces.py
Yeah, I remember poking around that code way back, and it seemed reasonable. Its interactions with transactions are the bits that scare me. Using a standard RDBMS connection would probably solve that though.
I revisited the SQLSession product a year ago for a consuling customer, making their hacked version a drop-in replacement for the transient storage. I can't release their code, but I maybe learned enough then to redo the task as a "PluggableSessions" product, using the "PluginRegistry" product to manage the different requried bits. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCXGYNGqWXf00rNCgRAqgqAJ9YjRNE1yqZKOXrl4nWlLCNaa/LvwCffVLH nqNZzuOutIv9hMTkIWfPu1w= =rrHr -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 13 Apr 2005 10:21 am, Tres Seaver wrote:
Richard Jones wrote:
Yeah, I remember poking around that code way back, and it seemed reasonable. Its interactions with transactions are the bits that scare me. Using a standard RDBMS connection would probably solve that though.
I revisited the SQLSession product a year ago for a consuling customer, making their hacked version a drop-in replacement for the transient storage. I can't release their code, but I maybe learned enough then to redo the task as a "PluggableSessions" product, using the "PluginRegistry" product to manage the different requried bits.
Well, I have a ZSQLSessionDataManager implementation based on the standard SessionDataManager with some changes. It appears to work fine when I test our application (which makes heavy use of sessions). So far the SQL code is geared towards Postgres (and gadfly, I think). It'd need some tweaking to work on MySQL ('cos MySQL is *special*) and I'm not interested in doing that work ('cos MySQL is *special*). http://www.zope.org/Members/richard/ZSQLSessionDataManager Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCXhkFrGisBEHG6TARAjmiAKCCEa9AH/1l5LGx4py/CHhXb1X7hACfZiYE iFsD9cpdZgb8+7NwlVwethY= =nVP7 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Jones wrote:
On Wed, 13 Apr 2005 10:21 am, Tres Seaver wrote:
Richard Jones wrote:
Yeah, I remember poking around that code way back, and it seemed reasonable. Its interactions with transactions are the bits that scare me. Using a standard RDBMS connection would probably solve that though.
I revisited the SQLSession product a year ago for a consuling customer, making their hacked version a drop-in replacement for the transient storage. I can't release their code, but I maybe learned enough then to redo the task as a "PluggableSessions" product, using the "PluginRegistry" product to manage the different requried bits.
Well, I have a ZSQLSessionDataManager implementation based on the standard SessionDataManager with some changes. It appears to work fine when I test our application (which makes heavy use of sessions).
So far the SQL code is geared towards Postgres (and gadfly, I think). It'd need some tweaking to work on MySQL ('cos MySQL is *special*) and I'm not interested in doing that work ('cos MySQL is *special*).
Cool. Where is CVS for that, so that I don't bug you for features. ;) I could import it to cvs.zope.org, if you like. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCXoEbGqWXf00rNCgRAuhJAKCaV3P7/MRuBQD8oL6Awmofc42hYgCglex+ OY3hhWKBg05zs4IG5xmKNuk= =vYaS -----END PGP SIGNATURE-----
Tres Seaver wrote:
Cool. Where is CVS for that, so that I don't bug you for features. ;) I could import it to cvs.zope.org, if you like.
I'd like to add Oracle support since I need it myself, and when I have working changes would like to have them included in newer releases of ZSQLSessionDataManager. /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. "...and click? damn, I need to kill -9 Word again..." - b using macosx
On 4/14/05, Richard Jones <richardjones@optushome.com.au> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 13 Apr 2005 10:21 am, Tres Seaver wrote:
Richard Jones wrote:
Yeah, I remember poking around that code way back, and it seemed reasonable. Its interactions with transactions are the bits that scare me. Using a standard RDBMS connection would probably solve that though.
I revisited the SQLSession product a year ago for a consuling customer, making their hacked version a drop-in replacement for the transient storage. I can't release their code, but I maybe learned enough then to redo the task as a "PluggableSessions" product, using the "PluginRegistry" product to manage the different requried bits.
Well, I have a ZSQLSessionDataManager implementation based on the standard SessionDataManager with some changes. It appears to work fine when I test our application (which makes heavy use of sessions).
So far the SQL code is geared towards Postgres (and gadfly, I think). It'd need some tweaking to work on MySQL ('cos MySQL is *special*) and I'm not interested in doing that work ('cos MySQL is *special*).
ark! insufficient priveleges Insufficient Privileges You do not have sufficient privileges to view this page. If you are getting this message when trying to edit your own zope.org content, remember that you must retract published items before you may edit them. To retract an item, click on the State link to view the publishing status form and select "retract" from the publishing options. If you believe you are receiving this message in error, please send an e-mail to webmaster@zope.org.
Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCXhkFrGisBEHG6TARAjmiAKCCEa9AH/1l5LGx4py/CHhXb1X7hACfZiYE iFsD9cpdZgb8+7NwlVwethY= =nVP7 -----END PGP SIGNATURE----- _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- http://myzope.kedai.com.my - my-zope org
Bakhtiar A Hamid wrote:
On 4/14/05, Richard Jones <richardjones@optushome.com.au> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 13 Apr 2005 10:21 am, Tres Seaver wrote:
Richard Jones wrote:
Yeah, I remember poking around that code way back, and it seemed reasonable. Its interactions with transactions are the bits that scare me. Using a standard RDBMS connection would probably solve that though.
I revisited the SQLSession product a year ago for a consuling customer, making their hacked version a drop-in replacement for the transient storage. I can't release their code, but I maybe learned enough then to redo the task as a "PluggableSessions" product, using the "PluginRegistry" product to manage the different requried bits.
Well, I have a ZSQLSessionDataManager implementation based on the standard SessionDataManager with some changes. It appears to work fine when I test our application (which makes heavy use of sessions).
So far the SQL code is geared towards Postgres (and gadfly, I think). It'd need some tweaking to work on MySQL ('cos MySQL is *special*) and I'm not interested in doing that work ('cos MySQL is *special*).
ark! insufficient priveleges
Works now ! Michael -- http://zope.org/Members/d2m http://planetzope.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 15 Apr 2005 05:54 pm, Michael Haubenwallner wrote:
Bakhtiar A Hamid wrote:
Richard Jones wrote: http://www.zope.org/Members/richard/ZSQLSessionDataManager
ark! insufficient priveleges
Works now !
Well, it does *sometimes*. Whenever I make a new release though, the zope.org permissions seem to be screwey and end up giving people an error when they try to view the page! So I made two releases in quick succession today, and whoever manages zope.org did get those releases through publication quickly (though again, the page came up as an error in the mean time). Unfortunately, an erroneous release I made - which I did not mark for publication that I'm aware of, and had a meaningless ID - was also published. I've now marked it as retracted (there doesn't appear to be any way to *delete* a release), meaning the ZSQLSessionDataManager is again inaccessible by regular users. Sigh. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCX4aorGisBEHG6TARAhSJAJ4qsrn7hHcc4MP3qftObcQlfF/7LACcCZQe NIrUvoBbIvplD/s0jZuelLc= =0gfa -----END PGP SIGNATURE-----
Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 15 Apr 2005 05:54 pm, Michael Haubenwallner wrote:
Bakhtiar A Hamid wrote:
Richard Jones wrote:
ark! insufficient priveleges
Works now !
Well, it does *sometimes*. Whenever I make a new release though, the zope.org permissions seem to be screwey and end up giving people an error when they try to view the page!
So I made two releases in quick succession today, and whoever manages zope.org did get those releases through publication quickly (though again, the page came up as an error in the mean time). Unfortunately, an erroneous release I made - which I did not mark for publication that I'm aware of, and had a meaningless ID - was also published. I've now marked it as retracted (there doesn't appear to be any way to *delete* a release), meaning the ZSQLSessionDataManager is again inaccessible by regular users. Sigh.
Hi Richard, that is a very old problem with software releases - any 'private' file inside the current release blocks the access to the release and only folder_contents works for some roles. You can retract the file it is in 'private' state and you remove it from the folder yourself. It takes some time for the caches to update too. Michael -- http://zope.org/Members/d2m http://planetzope.org
On Tue, 2005-04-12 at 20:01, Richard Jones wrote:
On Wed, 13 Apr 2005 09:44 am, you wrote:
On Tue, 2005-04-12 at 19:08, Richard Jones wrote:
Is there a viable non-versioned alternative to the filestorage approach? My sessions database grows ridiculously quickly. I'm also fairly sure it's causing problems when my site gets ~5 requests a second (yes, that low)
You could use temporarystorage on the ZEO server if you don't really need your session data to be persistent across ZEO server restarts. This is what Fernando appeared to do in the end.
Having sessions persist across ZEO restarts is a handy thing.
Yup. I've not really needed it so far, but if you need it, you need it...
Also, I never figured how to configure a temp storage in a ZEO server. I started looking once, but either ran into a dead end or got distracted (or both ;)
Probably something like what Fernando had on the client: <zodb_db temporary> mount-point /foo/bar # ZODB cache, in number of objects cache-size 5000 <zeoclient> server localhost:8999 storage temp name zeotemporary var $INSTANCE/var # ZEO client cache, in bytes cache-size 20MB # Uncomment to have a persistent disk cache #client zeo1 </zeoclient> </zodb_db> And in the ZEO server's zeo.conf file: %import tempstorage <temporarystorage temp> name sessions </temporarystorage> This resource is useful too: http://longsleep.org/howto/sharesessionwithzeo
There are no well-maintained nonundoing storages that I know of other than temporarystorage. Once upon a time, BerkeleyStorage minimal used to work, but its gone the way of the dinosaurs apparently.
And I distrust anything related to Berkely DB :)
I hear ya! ;-)
I think any sessioning setup that uses a ZEO-backed storage will be more conflict-prone than one that doesn't use ZEO, just because the transaction commit time is typically longer. I'm not sure if this is the problem you mention.
Could be.
It'd be pretty obvious with an inordinate number of conflict errors in the event log. "inordinate" is relative, though, so I'm not sure what to name as a number per minute for your app. You can get a sense of what's normal under contrived load by reading: http://www.plope.com/Members/dunny/conflicts/view
Probably not hard. You could write a "session data manager" implementation that used a relational database. The interface for those things is in Products/Sessions/SessionInterfaces.py
Yeah, I remember poking around that code way back, and it seemed reasonable. Its interactions with transactions are the bits that scare me. Using a standard RDBMS connection would probably solve that though.
Yeah. Probably OK to use a ZRDB connection, those are controlled automatically. - C
participants (7)
-
Bakhtiar A Hamid -
Chris McDonough -
Dario Lopez-Kästen -
Fernando Lujan -
Michael Haubenwallner -
Richard Jones -
Tres Seaver