On 11/18/05, Chris McDonough [EMAIL PROTECTED] wrote:
On Nov 17, 2005, at 4:46 AM, Dennis Allison wrote:
Thank Chris, good pointsB.
The session variable timeout is currently several hours as requird
by our
application. The timeout resolution remains at its default value.
Making
Dennis Allison wrote at 2005-11-15 14:54 -0800:
Has anyone prepared a set of best practice guidelines on the techniques to
use to minimize conflicts?
* Localize out into separate persistent objects attributes
with high write frequency.
E.g. when you have a counter, put into its own
Thanks Dieter.
On Fri, 18 Nov 2005, Dieter Maurer wrote:
Dennis Allison wrote at 2005-11-15 14:54 -0800:
Has anyone prepared a set of best practice guidelines on the techniques to
use to minimize conflicts?
* Localize out into separate persistent objects attributes
with high
Thank Chris, good pointsB.
The session variable timeout is currently several hours as requird by our
application. The timeout resolution remains at its default value. I have
not dorked with disabling the inband housekeeping. I don't see how it
would impact on our problem. Am I missing
On Nov 17, 2005, at 4:46 AM, Dennis Allison wrote:
Thank Chris, good pointsB.
The session variable timeout is currently several hours as requird
by our
application. The timeout resolution remains at its default value.
Making the resolution higher has been observed to reduce conflicts
Try to partition your collision space. Do you mount a shared temp_folder?
Don't! Do as Chris said and keep a temp_folder per ZEO client. Let the
load balancer send people to the same ZEO client every time (according to
the cookie).
Note that there is no solution for bad coding practice other
than
Chris,
I am aware that using ZEO to back session database is likely to increase
the opportunity for conflicts, but using a single session database seems
to be reaquired if you want, as we do, to distribute out interactive
application acrosss a cluster of processors cleanly.
Under our current
On Nov 16, 2005, at 6:18 PM, Dennis Allison wrote:
Chris,
I am aware that using ZEO to back session database is likely to
increase
the opportunity for conflicts, but using a single session database
seems
to be reaquired if you want, as we do, to distribute out interactive
application
Changing the architecture will likely get you the most bang but note
also that there are a few knobs that you can turn on the transient
object container UI that may limit the number of conflicts (in the
temp_folder/session_data_container):
- Data object timeout value -- the timeout value
Has anyone prepared a set of best practice guidelines on the techniques to
use to minimize conflicts?
It is becoming clear that we need to do to refactor some of our code to
get us out of our current conflict pickle.
A quick google produced lots of commentary but nothing I could hand to our
I don't know of any documentation but (correct me if I'm wrong) but
- install zope 2.8.0 or something higher that uses zodb 3.4
- use zeo's and load balancers so that certain requests don't clog your pipes
On 11/15/05, Dennis Allison [EMAIL PROTECTED] wrote:
Has anyone prepared a set of best
On Nov 15, 2005, at 5:54 PM, Dennis Allison wrote:
Has anyone prepared a set of best practice guidelines on the
techniques to
use to minimize conflicts?
It is becoming clear that we need to do to refactor some of our
code to
get us out of our current conflict pickle.
A quick google
Peter,
That's pretty much what we've done, but it is not really enough in
our case. Our sites are interactive with lots of per user state. We make
fairly heavy use of session variables to track the state. Our number of
simultaneous users is also fairly high. In addition, during development,
13 matches
Mail list logo
