B4J Question Websocket jetty server - using session ID

[LucaMs]

Do you think it might be a "good idea" to use the session ID as a "temporary user ID"?

To registered users I assign an ID created by the project and save it in a DB. Now I would like to allow access also to "guests", unregistered users (for whom I do not have the account data to associate that ID created); might it be a good idea to use the session ID for this purpose?


Note: clients are Android apps, not browsers.

 

[EnriqueGonzalez]

If these are android apps then no, there isn't any difference creating and id for anonymous users and regular customers.

Just create and id and fill the rest of the info when the user registers.

Remember that session id is deleted if you restart the server.

 

[LucaMs]

If these are android apps then no, there isn't any difference creating and id for anonymous users and regular customers.

The difference is that I don't have a database table for guests to write this temporary ID to.
Thinking about it better, they might have a nick created by the server, like Guest34239, and I might have a table with this nick and the same type of ID generated for registered users.

Remember that session id is deleted if you restart the server.

In that case I would lose all kinds of data in memory, so it doesn't matter if the session ID is lost.

 

[LucaMs]

It is probably useful to have an extra bolean field in the users table to indicate whether it is a registered user or a guest

 

[EnriqueGonzalez]

In that case I would lose all kinds of data in memory,

bad idea to keep everything in memory, you should always save first, sessions are not for storing not temp information, its just cache to prevent calling the database continously.

 

[LucaMs]

bad idea to keep everything in memory, you should always save first,

Temporary data and states that, at least in my case, are the majority, I prefer not to save them on disk as even assuming that it is not mechanical but SSD, for example, writing speed will certainly be much slower than that in RAM (which is still necessary), therefore it would weigh on the work of the server.

I could lose that data in case the server goes down but that shouldn't happen and if it happens once a year it wouldn't be a problem.

 

[EnriqueGonzalez]

Worrying for performance at this early stage of the project its shooting yourself in the foot.

If later you find issues storing in db (after 10 000 concurrent users) just add something like redis.

Redis

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker

redis.io

And you will be okey until 100 000

After that, just muy another server

 

[LucaMs]

Worrying for performance at this early stage of the project

In medicine it is said: "Better to be safe than sorry".
Better take care now of things that could create problems later.

Now I take a look at that Redis, anyway

 

[LucaMs]

Now I take a look at that Redis, anyway

I took a look, very superficially and quickly. It is always data in central memory, RAM, so I don't see the convenience, having also to learn a scripting language (LUA, whose name, among other things, makes me think of a disease ).

I will have some Maps that of course I will be able to manage through their keys, which does not seem very different to me and the loss of data in the event of an involuntary server stop will be the same (unless Redis saves also to disk - I don't think so - and then we would be at the same point previous one).

However we are going off the topic

 

[EnriqueGonzalez]

I took a look, very superficially and quickly.

Yes, the very first paragraph.

Redis is not a library, its more like an in memory db, you can also save to disk on a mon regular manner.

You are right we when off topic, my point is, you are over thinking the performance at this stage when there are strategies you can take in later stages when you already the know the demand for your product.