[Zope] FSSession atomicity?

[Curtis Maloney]

On Wed, 12 Apr 2000, Pavlos Christoforou wrote:
> On Tue, 11 Apr 2000, Curtis Maloney wrote:
> 
> > 
> > In fact, the logic of it only holds because it's happening.  
> > Otherwise I would have thought the session details would be written as
> > the FSSession dtml-calls occurred.
> > 
> 
> FSSession stores session data in a volatile attribute and only commits
> them on disk if the transaction successfully commits. It would be
> innefficient to access the disk everytime there is an update to the
> FSSession object not to mention that rolling back transactions would be a
> nightmare.
> 

Ok.. makes sense.

> A consequence of this is that if a user with the same Session UID tries to
> access his session info from a different thread before the first commits
> (as it would happen if a user points two browsers on Zope at the same
> time.... darn I suppose it could happen with frames too) then the second
> thread will not see the additions. I considered this possibility
> 'unnatural' but then again I did not think about frames then. 
> 

I'm not using frames, nor is anyone using two browsers at once (of this i can
be almost 100% certain, and I know it's happening when nobody else has access
to the box.)

> What does your log in code look like?
> 

The user login entry boxes are part of the standard header, so the check is
done on every page.  If the user is already logged in, their details are shown,
instead of the login boxes.  This is where the problem shows.

Here is my verify document, which is called when the user hits the Login submit
button:

<dtml-var standard_html_header>
<dtml-in "sqlPasswordCheck(user=username, company=company)">
  <dtml-if "passwd == Password">
    <dtml-call "FSSession.set('UserName',username)">
    <dtml-call "FSSession.set('ID',company)">
    <dtml-call "FSSession.set('Permissions', Permissions)">
    <dtml-var "RESPONSE.redirect(HTTP_REFERER)">
  </dtml-if>
</dtml-in>
<h2>Incorrect Login Attempt</h2>
<p>
<a href="<dtml-var HTTP_REFERER>">Try Again.</a>
</p>
<dtml-var standard_html_footer>

So, if the user logs in correctly, they are redirected to whence they came,
which would normally shunt them off to another page.  Would I be correct in
assuming that the cookie being set is a good indicator of a new transaction
beginning?  or one ending?

-- 
Have a better one,
	Curtis.

<dtml-var standard_work_disclaimer>