MySQL transactions/locks
-
So what environment would you recommend? Just curious.
-
Anything that can run as app outside of web requests. Based on my experience, C# self-hosted web API or node.js. But these are the things I know. I presume python, ruby, java, go and many others can achieve similar things. Not sure if there's a solution for PHP, though.
Ok, since @mott555 wants to learn PHP, here's a potential solution I'd consider:
- Install redis
- Every request processes user input and shoves it into a queue in redis.
- Cron runs a PHP script every second. It pops events from redis queue and executes them one by one. Since you control the flow, you can update MySQL as you normally would
- Clients connect and pull data from MySQL.
Of course, you'd still need something to return to clients that initiate actions. Maybe some kind of pooling or web socket solution.
-
Point taken, but part of the purpose of this project was to learn MySQL since I've only ever dealt with MS-SQL
Fair enough, but re-read his advice and consider how much you want to learn something that may go away.
-
Fair enough, but re-read his advice and consider how much you want to learn something that may go away.
MySQL isn't going away. See MariaDB.
-
MySQL isn't going away. See MariaDB
I'm not saying it's GOING to go away, but it's certainly at a lot higher risk of going away than almost any other DB engine. It's all about managing risk.
In any case, using PDO is just plain "the right way to do it", is really the point.
-
In any case, using PDO is just plain "the right way to do it", is really the point.
Agreed.
-
In any case, using PDO is just plain "the right way to do it", is really the point.
PDO may be doing it right, but writing a MUD engine in PHP is already wrong.
So I guess pick your battles, if you're going to do it for the sake of learning, you should use PDO to do it the right wrong waytm
-
It really depends on whether it's real time or not, as in 'pushing updates live to the browser' or responding to polling or simply just letting the user do things in their own time.
PHP is not entirely terrible, and I'd certainly argue there are better environments but it is when you start pushing at the limits of things that you understand their true power, at least in my experience.
Then again I've done fucking daemons in PHP before, and that ended badly - but it worked. Just gotta watch out for memory use since PHP's memory allocation isn't smart because it's designed for relatively short life scripts (and its GC is not entirely smart), but my point is, the language can let you almost anything even if you probably shouldn't, and you'll get to know all its foibles that way.
-
You shouldn't Fuck daemons arantor, they suck out your soul.
-
Dude... PHP. Personal Hell Pit. I don't have much of a soul left already.
And I'm certified in that shit too.
-
And I'm certified in that shit too.
The funniest part of this whole thread is the idea of PHP certifications. Do you get those from a psychiatrist?
-
No, you pay Zend some money and sit at a computer for half an hour and fill in this weird multiple choice test and then they send you a piece of cardboard all stamped and pretty.
-
StackOverflow won't let me post questions because I don't have enough reputation, yet somehow the most mentally-deficient programmers in the universe are able to get enough reputation to post advice that is The Worst Of The Worst.
Try doing some answers in one of the mid-traffic tags. If you're any good, you should be able to pick up rep dead easy. (Remember, focus on answering the question. Everything else is extraneous.) Low-traffic tags take ages for you to build up rep, and high-traffic tags (like
javaorc#) are watched by loads of people and so hard to participate in.And for fuck's sake, post links to the shitty answers here. Some of us have lots of rep and can deal with those turds.
-
And for fuck's sake, post links to the shitty answers here. Some of us have lots of rep and can deal with those turds.
When they give me a slice of the revenue, I'll give them my time.
-
You don't get any revenue from here, how come we get your time?
-
Ah but I do.
-
wut
-
He pimps his youtube feed and gets ad money from people who want to watch other people play video games.
-
And the people here actually go look?
-
Why do you think I came back? PJH sweetened the pot. I guess he looked at the web analytics and found I brought in traffic or something.
-
So how much do you charge by blakeyrant? Is it a growing market?
-
I gotta strike that kind of deal, if only to produce sufficient material for you to rant at.
-
I've dealt with a similar problem to this in a turn-based strategy game, and I came up with a solution that seems to work. It might not be appropriate for you (and it might even contain nasty bugs I haven't discovered), so keep that in mind.
If you're using MySQL with InnoDB, you can do "SELECT whatever FROM table WHERE conditions FOR UPDATE" during each transaction, and anything else that tries to select those rows will block until the transaction is committed. Of course, you can only maintain those locks for a short period of time, and you might need to be careful to lock things in a consistent order to avoid deadlocks - in my own project, I use a single "locks" table containing numeric type/id pairs for every lockable object (and do "SELECT * FROM locks WHERE (type,id) IN ((t1,v1),(t2,v2),(t3,v3),etc) FOR UPDATE") and have not run into problems with it (even when the periodic update script selects every row for update).
And if you're using transactions with InnoDB, you'll probably want to use the "READ COMMITTED" isolation level so you can query new values from the database tables after you've started a transaction (i.e. if you had to wait on a locked row, and data in another table changed in the meanwhile).
-
I agree with whatever Quietust just posted above.
-
-
Adblock FTW!
