Unique Identifier For Session

I have a slot booking app. What i want is lock a slot 5 minutes for a session/user. I added lock_until, locked_for attributes to slots. A user has id, but what is equivalent thing for a session. Also if there are another approaches can you please share?

I’m not sure what a slot booking app is, could you clarify what you’re trying to do a bit more? Are you trying to ensure a user in a Phoenix application gets logged out every 5 minutes?

1 Like

There is a slot locking mecanism in this video

around 25 minutes… If this is what You are looking for.

Basically You want to lock a slot for a booking application for 5 minutes? Probably because each booking reduces the capacity of your stock, and You don’t want to sell more than what You can provide.

He wants to lock a timeslot for a user to order something, so no other user could bypass this by typing faster. There is not even the need to store lock_until, just spawn a process with locked_for, and a timeout. As soon as the process expire, so does the lock.

Each resource has a capacity, when You want to book, You request an access, that will decrement capacity, in case You don’t fill the booking in 5 minutes, the token expires without being used, and capacity is increased.

Is that what You want to do?


I am trying to avoid concurrent data access. Like a cart timeout and decrease quantity when a item added in a cart. But i don’t want to use serverside cart because users will choose only on slot, also if i use cart i will need to delete inactive carts with cron job. That is only want to lock a slot 5 minutes for a user and session so while a user progressing payment another users wont able buy that slot. My problem is that i am able to that with a user because a user has a id. So i can lock a slot for user. But how can i able to do that with a guest session.Has a session unique id or something? Server side can determine a difference of sessions as a user? Sometimes i dont know limits of programing. Maybe completely meaningless question…

@kokolegorille i will check it thanks.

Yes this is exactly what i want. Looks like this case is great for dive in genserver, ets.

Also still i dont know how to achieve that from server side for a guest session ?

The trick with such identifiers is, that you can use whatever you like and write it into the session…

I’m not experienced with phoenix, but have you considered using it roughly like this?

def create_token() do
  uuid = UUID.generate_v4() # you probably need to get a UUID package, therefore this is pseudo code
  Phoenix.Token.sign(YourApp.Endpoint, "your secret salt", uuid)

def validate_token(token) do
  Phoenix.Token.verify(YourApp.Endpoint, "your secret salt", token, max_age: 5 * 60)

You can store and retrieve that Token via Plug.Conn.{fetch,get,put}_session.


I never thought this would be easy like that. Just store a thing make session unique… really thanks.

Instead of using an UUID, you could use make_ref() |> :erlang.term_to_binary() to create a string-representation of an almost surely unique reference (The keyspace is 2^82), whose behaviour is provided to you by the Erlang VM.

1 Like

I’ve chosen UUID in my example as it is widely known and understood.

Of course on can choose any mechanisms one likes, even a simple counter is possible.

1 Like

You could also put the slot id for the user in a phoenix token even with a timeout for the token to be valid. You could give that to the client and let it represent it for the final booking or just use the session to keep it around.

1 Like

With a token expiry it is harder to manage stock quantity, because it is hard to detect when a token expires when not used.

Sure, but it takes load from the db so if the token is long expired you don’t even need to check the db anymore. You’ll still ned to expire reserved slots independently from the client.

1 Like

One could even sign the token with a :signed_at time.

That time could be written to the database and when looking for available solts, we look for all WHERE blocked_since < five_minutes_ago OR blocked_since IS NULL (well, actually I mean the SQL that comes closest in its semantic to my pseudo-SQL :wink: ).

So no useless lookups or writes to “free” a slot.

1 Like