Lockless means sometimes decryption fails?

[warvenSniper]

For this great project i have some question，

1. Now, i am worried about the impact of using locks on performance, so i want to use it in lockless and i suspect that the following scenario will cause the decryption to fail: There are two concurrent requests and the cookie is same now.
2. req1 was processed first : req1 updated and saved the session.data and the cookie(hmac) will also be updated
3. req2 was processed later : now the cookie for req2 is outdate, means the condition would return false:

Sorry for my poor English.

[bungle]

Locking only happens per session, it has no impact on other sessions. Whenever you use session for writing, you should call session:start as late as possible and after that session:save as soon as possible. Right now if you open session for reading with session:open, and that will also do locking (if enabled). For that we need to add session:close (that we don't currently have). So then you could use patterns:

local s = session.start()
-- read and/or write
s:save() -- or perhaps s:destroy()

And

local s = session.open()
-- read-only
s:close()

I will add that soon. But for your use case, you cannot really make two parallel request without any locking, and because your another call may change the session, you need to update second one to send that updated session cookie (browsers do this automatically). In general you should minimize the places where you change session data, and often you should store bare minimum in session (such as user_id).

You can always use cookie storage (which is default). That is always lockless.

[bungle]

Closing this as closewas added long time ago.