Left several entries in order to free up points to enter a new game... none of those show up in the points overview - so effectively kicked me out of the ga's but 0p returned... i'm lacking now 103 points!! I cannot post these giveaways here as they are all hidden ga's.

View attached image.
8 years ago

Comment has been collapsed.

Happened to me several times too.

8 years ago
Permalink

Comment has been collapsed.

sry to hear man. First time for me though.

8 years ago
Permalink

Comment has been collapsed.

OH NO!!!!! ;0

8 years ago
Permalink

Comment has been collapsed.

They killed ... "points" :O

8 years ago
Permalink

Comment has been collapsed.

who cares?

8 years ago
Permalink

Comment has been collapsed.

Why did you waste your time even to reply :P

8 years ago
Permalink

Comment has been collapsed.

Apparently they wanted to let you know they care! =O
Just only that much :P

8 years ago
Permalink

Comment has been collapsed.

win98 theme rocks!

8 years ago
Permalink

Comment has been collapsed.

Yeah i like the clean classic theme... no extra spoilers, no transparency parts but readable and functional :)

8 years ago*
Permalink

Comment has been collapsed.

Database doesn't use transactions, or for any other reason requests which should be queued synchronously are not, therefore based on workload any requests from 1 to X (where X is the number of queued requests at given time) will execute properly.

Something like:
We have 130 points, we quit 2 giveaways for 20 and 10 points.

  1. A: Add 10 points
  2. B: Add 20 points
  3. A: Current points is 130
  4. B: Current points is 130
  5. B: 130 + 20 is 150.
  6. B: Set points to 150.
  7. A: 130 + 10 is 140.
  8. A: Set points to 140.

We expect to have 130 + 20 + 10 = 160 points, but we got only 140.

It can be also abused when spending points, if the mechanism uses same logic (should be).

8 years ago
Permalink

Comment has been collapsed.

Are you trying to tell that SG still uses mysql myisam tables? Thats.... stone age. :O

8 years ago
Permalink

Comment has been collapsed.

I don't know what it's using, I say how it looks like to me. Even if they use something new like InnoDB, it's still possible that a guy who coded the site doesn't know how to start and end SQL transation. Single SQL transation is locked, but two independent ones are not and it's totally possible that if you execute 1-2-3-4 asynchronously you may actually get 3-4-1-2 or other combinations.

Some people also disable transactions for performance reasons, sigh.

8 years ago
Permalink

Comment has been collapsed.

Yeah concurrency is a tricky part of programming. Always a great source of mishap.. Transactions need to be manually initated and completed. The DB designer might not be aware of that. The clever would use stored procedures to let the db subtract/add values so db works on a sane base. So even when asyncronously hit (and transactions locking down too long/too much) they would keep the state clean. That might be a solution.

I too can't stand the idea of sacrficing integrity for speed. Thats a tradeoff that will backfire eventually.

[update] Still asking myselves if a "update set points = least( points + value, 300) where id = userid & value < 300" could do the trick too as also keeps the data integer by not querying it before. And its a single query only -> fire and forget :)

8 years ago*
Permalink

Comment has been collapsed.

It doesn't work like that, that query includes subquery, and transaction holds only one (write) lock. Until you explicitly declare that you want to hold the whole (exclusive) lock for entire table during procedure/query execution, it's totally possible that I'll update points in between your subquery and main query. And holding exclusive lock is expensive, therefore it's better to write independent queries and lock them together where it's essential.

For example:

UPDATE users SET points = points + 20 WHERE user_id=XXX;

And a trigger BEFORE_UPDATE:

IF NEW.points > 300 THEN
SET NEW.points = 300
END IF;

Above example is lock-safe as long as normal transaction lock is held during UPDATE statement.

8 years ago*
Permalink

Comment has been collapsed.

Using triggers seems rationally the best way to do. Didn't even thought of it. Why not suggesting that solution to cg... he seems to be do maintaining work on the database anyways as of now.

Thanks for pointing out that my update query did trigger a subquery - wasn't aware of that. That would lead to the dilemma i was trying to solve.

As a sidenote... i thought that db systems would do that on their own behalf - i mean aggregating queries and combine those who can be combined. Or does that need another hint given through the syntax?

8 years ago
Permalink

Comment has been collapsed.

It depends on specific DBMS, and we have plenty of those. I don't know what SG is using, so I can't give you specific answer, I can just suggest checking documentation of the ones you're interested in.

Yes, they SHOULD do that, but avoiding subqueries is essential also for performance reasons. People tend to use easier WHERE XXX IN statements instead of e.g. INNER JOINs. I'm not an expert when it comes to databases, I just know enough to write fairly efficient queries and not struggle in concurrency problems (for longer than it's needed).

Speaking of MySQL/MariaDB for example, there is only one default lock - the write lock, which ensures that 2 update/insert/delete queries executed at the same time will be executed properly. However, there is no default read lock, so if you use e.g. UPDATE with hidden SELECT subquery, it's possible that I can change the value after your select, and before your update.

8 years ago
Permalink

Comment has been collapsed.

That seems like it'd explain my history of vanishing points..
Thanks for the insight :)

8 years ago
Permalink

Comment has been collapsed.

Yeah thanks for pointing out. The current db issues and the long lag spikes seem to amplify the underlying problem :<

8 years ago
Permalink

Comment has been collapsed.

I think the conclusion here is - don't drop out of more than one GA at a time.

8 years ago
Permalink

Comment has been collapsed.

That's the workaround. The conclusion is that they should fix it. I wouldn't hold my breath for that though.

8 years ago
Permalink

Comment has been collapsed.

Yups... thats what i learned in the same process. Well not fixing it would display incomptetence in tackling the serious pitfalls of programming. Not likely to happen :)

8 years ago
Permalink

Comment has been collapsed.

Yup, happened to me too, lost around 200 points. But worse was when I kept removing entries from like 20 GAs, and then realized I'd hit the 300 cap some time ago ;_;

8 years ago
Permalink

Comment has been collapsed.

My condolences.. thats even worse ;_;

8 years ago
Permalink

Comment has been collapsed.

I can give you all my 300p :D i have 300/300 in 99% time (no gibs to enter, maybe bcs 4350 blaclisted)
[H] 300p [W] great games :)

8 years ago
Permalink

Comment has been collapsed.

Well you have me blacklisted :D, you're the only person I know about that has me on blacklist.

8 years ago
Permalink

Comment has been collapsed.

O.o i don't know why... :D

8 years ago
Permalink

Comment has been collapsed.

Sign in through Steam to add a comment.