Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overwriting the Existing record #361

Closed
abhiCR7 opened this issue Sep 13, 2016 · 6 comments
Closed

Overwriting the Existing record #361

abhiCR7 opened this issue Sep 13, 2016 · 6 comments
Labels

Comments

@abhiCR7
Copy link

abhiCR7 commented Sep 13, 2016

I have 2 parallel requests(R1 and R2) . Both of them write some data in the record(record D1). So it's kind of race condition. If R1 writes something to the D1 and it gets persisted, then R2 writes something to the in-memory copy of D1 and saves it which results in loss of data written by R1(vice versa).
Is there anyway where we can write the only diff in the record instead of overwriting the whole record

@gabeio
Copy link
Member

gabeio commented Sep 13, 2016

Well you could do this by defining the value that is being overwritten in the database separately from the session. that way you can control the access to that value separately. Thusly can do a read/write lock/mutex (most sql databases do this) on the row so that only one of those requests can be processed at a time and there then is no race condition (assuming you are using a database which can row lock otherwise you will have to use an application defined mutex for a virtual row lock and have your application check grab the lock before reading / writing the value to assure it's the only one read/writing and that it's not going to be read/written until it unlocks it).

@abhiCR7
Copy link
Author

abhiCR7 commented Sep 15, 2016

@gabeio Thanks for your response.
I get your point and that's the ideally it should be done.
But the thing is that the info i intend to store in sessions is valid until the session exists for that particular user(until logged in).
So in case of the storing in another database would result in having a background job which will delete that info once the session is invalid(expired). This is the problem with using separate database.
I will think of another solution if possible or else i'll store the info different database.
Meanwhile is there any way we I can know each time when a session record is invalidated (i mean expires)?

@gabeio
Copy link
Member

gabeio commented Sep 15, 2016

Meanwhile is there any way we I can know each time when a session record is invalidated (i mean expires)?

server side? or client side (there's a huge difference)

@abhiCR7
Copy link
Author

abhiCR7 commented Sep 20, 2016

Sorry for the delay.
Server side only, so then i can store the data in separate table and as and when a session record is invalidated i can catch the event maybe.

@dougwilson
Copy link
Contributor

Is there anyway where we can write the only diff in the record instead of overwriting the whole record

This would be a behavior that would need to be done with your store module; this module simply hands all the data to your store module, which can decide how to persist it to the database (either complete overwrite, or something else).

Server side only, so then i can store the data in separate table and as and when a session record is invalidated i can catch the event maybe.

This would also be an operation done by your store module. The store module you are using has access to all the session expirations, etc. You can pretty much think of this module as being the glue between the request and your session store, exposed to Express. Any time a request comes in, this module simply asks your store module to find it, and when complete, tells the store module to persist it.

This module would not have a way to track it, since it doesn't have access to the underlying database. This module lives in the memory of your Express server, and can only work on that information. For example, if you scale your Express app to 15 servers, if sess#1 was seen by server#4 to expire in 2 hours, then server#4 never way that session again since it kept hitting other servers, you would not want to accidentally think the session expired 2 hours after server#4 saw it, even though it has not expired, as it was active still.

@abhiCR7
Copy link
Author

abhiCR7 commented Sep 28, 2016

Thanks for the info @dougwilson :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants