Live data from Hacker News

Dumb website only lets one user in at a time

imherefor.me

31–40 of 104 posts

Re: Dumb website only lets one user in at a time

#31
post #27

I once worked for a Cambridge startup called Sayagle where you would Yagle for SayaCash (don't ask). I started after the website was built by a cheap offshore team. It was built with JSF and we soon found that no one thought about multithreading because they only ever tested it with a single user. Needless to say, when more than 10 users were active on the site, they would start to experience problems, like seeing ea…

>> they would start to experience problems, like seeing eachothers data and stuff. Wait, what? I'm going to need some explanation or story time about how this happened.

It's not that uncommon in some languages where you have a long running monolith (.NET, Java, etc) instead of an instance of something that spins up per request (Node, PHP, etc). If someone does something silly like setting the session handler to be scoped to the monolith app rather than having a scope of a single request you end up with users seeing one another's data. It's dangerously easy to do in some frameworks.

Re: Dumb website only lets one user in at a time

#32
post #27

I once worked for a Cambridge startup called Sayagle where you would Yagle for SayaCash (don't ask). I started after the website was built by a cheap offshore team. It was built with JSF and we soon found that no one thought about multithreading because they only ever tested it with a single user. Needless to say, when more than 10 users were active on the site, they would start to experience problems, like seeing ea…

>> they would start to experience problems, like seeing eachothers data and stuff. Wait, what? I'm going to need some explanation or story time about how this happened.

The idea was that you would visit participating merchants, spend money there and they would give you codes on stickers that they generated from our site and then the customers would use those codes on the site with purchase amount to get sayacash. One problem we had was that the codes we generated turned out to be invalid because... we didnt know why. We generated the codes, but they werent in the database. Where did they go? The customers would try to enter them, and be told that they are invalid, or go to their dashboard and see stuff that wasnt theirs because there was only one session object for the entire app.

It was a huge mess. At some point we made a video that would explain how the site was to be used. You can find it here: https://www.youtube.com/@sayagle.

Every single person in every video was employed by this company. The tea place in the first video was owned by the founder. :)

Re: Dumb website only lets one user in at a time

#33
post #13

The queue here seems to work poorly. Looked at the site and I was 162. Looked away and back for literally 2 seconds, I was 164. alt tab and back again, I was 176. Again and I was 188/188. Now I'm 140. What?

I've been going back and forth between position #4 and #3 for a while now, which is a bit confusing.

Re: Dumb website only lets one user in at a time

#38
post #31

Earlier quoted context omitted.

>> they would start to experience problems, like seeing eachothers data and stuff. Wait, what? I'm going to need some explanation or story time about how this happened.

It's not that uncommon in some languages where you have a long running monolith (.NET, Java, etc) instead of an instance of something that spins up per request (Node, PHP, etc). If someone does something silly like setting the session handler to be scoped to the monolith app rather than having a scope of a single request you end up with users seeing one another's data. It's dangerously easy to do in some frameworks.

Sadly I’ve seen this happen just recently… with new code… written by someone who has over a decade of “experience”.

It’s sufficient to simply use the “static” keyword or a singleton service that should be scoped to the session.

The sad thing is that the default is the happy path, you have to go out of your way to break the session scoping by “being too clever”.

Re: Dumb website only lets one user in at a time

#39
post #31

Earlier quoted context omitted.

>> they would start to experience problems, like seeing eachothers data and stuff. Wait, what? I'm going to need some explanation or story time about how this happened.

It's not that uncommon in some languages where you have a long running monolith (.NET, Java, etc) instead of an instance of something that spins up per request (Node, PHP, etc). If someone does something silly like setting the session handler to be scoped to the monolith app rather than having a scope of a single request you end up with users seeing one another's data. It's dangerously easy to do in some frameworks.

Stateful singletons (and/or shared classes) are _probably_ a more common blunder than session scoping.

Re: Dumb website only lets one user in at a time

#40
Not at all the same thing I admit, but the company I work for has a product that limits the number of transactions (per user) to 1. Where "transaction" is roughly equivalent to an HTTP request. So if you run a query that takes 30 seconds, get bored, open up a new tab to do something else in the product, your new tab will hang until the transaction in the previous tab has completed.

I hate it.

There is a special URL that will kill your running transaction. All of the engineers know it and have it bookmarked, but it's undocumented.

Post reply on HN