| *** tpb has joined #tp | 00:00 | |
| *** ChanServ sets mode: +o tpb | 00:00 | |
| *** mithro has joined #tp | 00:38 | |
| *** mithro_ has joined #tp | 01:00 | |
| *** mithro has quit IRC | 01:01 | |
| mithro_ | bddebian: ping? | 01:36 |
|---|---|---|
| *** JLP has quit IRC | 05:06 | |
| *** gau_veldt has quit IRC | 05:30 | |
| *** mithro_ is now known as mithro | 06:38 | |
| *** zzorn_ has quit IRC | 07:06 | |
| *** JLP has joined #tp | 07:30 | |
| JLP | good morning everyone | 07:30 |
| mithro | hey JLafont | 07:35 |
| mithro | opps | 07:35 |
| mithro | hey JLP | 07:35 |
| mithro | do you run Suse? | 07:35 |
| JLP | mithro: nope, mandriva | 07:35 |
| JLP | and gentoo | 07:36 |
| mithro | whats mandriva use to install stuff? | 07:36 |
| mithro | with debian/ubuntu it's apt-get | 07:36 |
| mithro | with suse it seems to be zypper | 07:36 |
| JLP | rpm and apt-get like extensions called urpmi | 07:36 |
| mithro | JLP: do you want to see if you could get the following working on mandriva - http://wiki.python-ogre.org/index.php/LinuxBuildV2 | 07:37 |
| tpb | <http://ln-s.net/2VC0> (at wiki.python-ogre.org) | 07:37 |
| mithro | if you can, then we can add it to the set of RPMs builds | 07:38 |
| *** peres has joined #tp | 07:41 | |
| JLP | mithro: will try, later when i book into mandriva | 07:43 |
| JLP | btw how was the summit | 07:45 |
| *** zzorn_ has joined #tp | 08:04 | |
| *** zzorn_ has quit IRC | 08:31 | |
| *** mithro has quit IRC | 09:30 | |
| *** mithro has joined #tp | 09:48 | |
| *** mib_4h10lxec has joined #tp | 10:51 | |
| *** gau_veldt has joined #tp | 10:52 | |
| *** mib_4h10lxec has quit IRC | 11:04 | |
| *** mithro has quit IRC | 11:11 | |
| *** mithro has joined #tp | 11:31 | |
| *** peres has left #tp | 11:42 | |
| *** nash has joined #tp | 17:18 | |
| *** nash has quit IRC | 17:21 | |
| *** nash has joined #tp | 17:22 | |
| gau_veldt | hello | 18:33 |
| gau_veldt | what does tpserver-py use for its database backend? sqlite or mysql? can it be changed easliy (say from sqlite to mysql)? | 18:34 |
| gau_veldt | I'd like to use mysql so other things could use the database than just the server | 18:35 |
| *** Greywhind has quit IRC | 18:35 | |
| gau_veldt | say like something that figures out statistics within the universe to present web pages about the universe and stuff like that | 18:36 |
| *** Greywhind has joined #tp | 18:36 | |
| gau_veldt | (03:36:06 PM) gau_veldt: say like something that figures out statistics within the universe to present web pages about the universe and stuff like that | 18:36 |
| *** mithro has quit IRC | 18:36 | |
| gau_veldt | well darn no one seems to be holding their connection right now :( | 18:37 |
| tansell | gau_veldt, the tpserver-py can use any DBA compliant database | 18:47 |
| tansell | it's been tested mainly with sqlite | 18:47 |
| tansell | but should work with mysql (as long as you use InnoDB tables) | 18:48 |
| gau_veldt | DBA-compliant? | 18:48 |
| gau_veldt | and what does InnoDB have the others like MYISAM don't that tP requires? | 18:49 |
| gau_veldt | does DBA-compliant just mean it's ACID or is there deeper requirements? | 18:52 |
| gau_veldt | Like I said I'm thinking of having other processes use the DB so ACID would be good actually | 18:56 |
| tansell | MyIASM doesn't have transactions | 19:08 |
| tansell | which the tpserver-py depends on | 19:08 |
| tansell | DBA is a python access layer specification | 19:09 |
| tansell | tpserver-py makes very heavy use of transactions for things like turn processing | 19:09 |
| tansell | so if a processing fails halfway though you don't get a corrupt db | 19:10 |
| gau_veldt | yeah I understand transactions - it's an ACID thing | 19:10 |
| tansell | well, it doesn't use a lot of ACID | 19:10 |
| tansell | just transactions | 19:10 |
| gau_veldt | well ACID is a compsci term meaning Atomicity, Consistency, Isolation, Durability | 19:11 |
| gau_veldt | I think it would need all of those actually | 19:12 |
| gau_veldt | sounds like everything the transaction concept is engineered to provide | 19:13 |
| gau_veldt | I just wonder how it works when you have to make decisions based on state within a transaction | 19:14 |
| gau_veldt | the example is usually that you post a debit and credit atomically | 19:14 |
| gau_veldt | by using a transaction | 19:14 |
| gau_veldt | but where do you fit in the "debit only possible if account>debit_amount" requirement? | 19:15 |
| tansell | like I don't care about referential integrity much | 19:15 |
| gau_veldt | and that has all sorts of race situations so it really DOES have to be atomic | 19:16 |
| gau_veldt | like you don't want something else debiting the remainder of the account between passing the >debit_amount check and the actual debit | 19:16 |
| gau_veldt | so I'm guessing the acount row would lock and any other transactions on that acocunt would have to wait in queue | 19:17 |
| tansell | transactions are basically a "scratch disk" | 19:18 |
| tansell | IE you do all the changes, then you save it onto the main disk | 19:18 |
| gau_veldt | but like above what happens when you use information based on state like I just showed? | 19:19 |
| gau_veldt | the decision needs to be done in the same atomicity | 19:19 |
| gau_veldt | otherwise you could race the account and debit the last of the money immediately after the if >amount check passes? | 19:20 |
| gau_veldt | race conditions of course being possible in any process that isn't completely atomic | 19:21 |
| gau_veldt | all the mysql stuff I've seen says to add the modifiers to the query to enforce the > rule but alas my example is too simple to break that but I can think of situations where the expression would be more easily parsed in the actual code doing the DB access than the query itself | 19:22 |
| gau_veldt | simple example might be a DB representing a linked list type setup where there are no nice SQL modifiers to make decisions based on the child/parent fields | 19:23 |
| gau_veldt | my worry (from the descirpitons at least in mysql transactions that I've read) is that when the app does its own checking mysql may not lock everything that needs to be locked between the decision making and the resultant updates | 19:25 |
| gau_veldt | "reads may not be consistent throughout the transaction" seems to be the default locking mode which scares the #$@%@# out of me | 19:25 |
| tansell | in theory with a transaction you don't need to lock | 19:42 |
| tansell | you only need to lock on write | 19:42 |
| tansell | transactions generally work in the form "collect a bunch of changes and apply at once - if any one fails, then they all fail" | 19:42 |
| gau_veldt | well for a transaction to truly be atomic you need to have consistent reads throughout like if you pass the account>debit test then at the point of the deduction it should still be true even if many many miliseconds have passed since the if check | 19:43 |
| gau_veldt | if you don't lock the read you could have two dbits going on at once both believing they have enough money in the account left | 19:44 |
| gau_veldt | but the sum of the debits is greater than the remaining account | 19:44 |
| gau_veldt | (each debit a separate transaction) | 19:45 |
| tansell | one of the transaction would fail as the underlying data changed | 19:45 |
| gau_veldt | okay here goes | 19:45 |
| gau_veldt | debit 1: check account >b | 19:45 |
| gau_veldt | debit 2: check account >c | 19:45 |
| gau_veldt | (both tests pass) | 19:45 |
| gau_veldt | debit 1: subtract | 19:46 |
| gau_veldt | debit 2: subtract | 19:46 |
| gau_veldt | on commits account now negative | 19:46 |
| tansell | nope | 19:46 |
| tansell | one of the commits will fail | 19:46 |
| tansell | with "data no longer consistent" | 19:46 |
| tansell | meaning that one of the values you read/used changed before you did a commit | 19:46 |
| gau_veldt | so my bank would then give me some stupid "unkonw error $53137" please try again | 19:47 |
| tansell | it would probably just run the code again | 19:48 |
| gau_veldt | and I'd be switching banks becuase their site was such a pain to use | 19:48 |
| tansell | and then the check account >c would fail | 19:48 |
| gau_veldt | preferably the read should lock | 19:49 |
| gau_veldt | so that the transactions have to queue | 19:49 |
| gau_veldt | though I suppose anything more complicated than a single select might spell philosopher's dinner type trouble | 19:50 |
| tansell | the read lock doesn't solve anything | 19:50 |
| tansell | except slows everything down in the uncommon case where the above happens | 19:50 |
| gau_veldt | so a commit will fail if a row you select on is dirtied by other concurrent transactions? | 19:51 |
| gau_veldt | so then both transactions might fail and try again and both fail then try again then fail then try again ... | 19:52 |
| gau_veldt | then no philsopher will be able to eat first | 19:52 |
| gau_veldt | unless one of the philosphers is superman and can eat his entire meal before the pihlosophers net to him realize they need their fork | 19:53 |
| gau_veldt | and in the age of net lag even superman may not be able to achieve that | 19:54 |
| tansell | no | 19:54 |
| tansell | because a transaction can only dirty a read value if it is successfully committed | 19:54 |
| gau_veldt | so "first philsopher to the fork gets to eat" then? | 19:56 |
| tansell | yes | 19:57 |
| gau_veldt | everyone else having to leave then come back | 19:58 |
| tansell | well no | 19:58 |
| tansell | half the philsophers will get to eat | 19:59 |
| tansell | the other half will have to wait | 19:59 |
| tansell | (well roughly half) | 19:59 |
| gau_veldt | well the there's no queue so they aren't waiitng | 19:59 |
| gau_veldt | tom me failing on the commit due to dirtiness is being ejected fromt he meal and having to come back for the next meal session afte the dishes are washed | 19:59 |
| gau_veldt | aka unix EAGAIN | 20:00 |
| gau_veldt | or the "spin to you can" error | 20:00 |
| gau_veldt | *till you can | 20:00 |
| tansell | it's better then everyone waiting for the first philosopher to finish then the next one then the next one | 20:00 |
| tansell | as half get to go straight away | 20:01 |
| tansell | the rest can go as soon as the first lot finish | 20:01 |
| gau_veldt | well in the DB case they have to wait for the utnesils to be laundered first | 20:01 |
| gau_veldt | so a really unlucky philospher could well not get to eat if new philosphers make it to the dinner before him | 20:04 |
| tansell | and it turns out in 99% of the cases it's preferable to do this | 20:04 |
| tansell | as it scales | 20:04 |
| tansell | you do get a percentage which never get to eat | 20:04 |
| tansell | but that's better the no-one getting to eat | 20:04 |
| gau_veldt | so there'd be a palyer somehwere who never gets to play | 20:05 |
| gau_veldt | or a bank client who can never get any money from their account | 20:05 |
| tansell | gau_veldt, but the case is very rare (in computer systems it's like the same posibility of getting hit by falling space junk) | 20:06 |
| tansell | so the space junk will take care of them for you ;) | 20:06 |
| gau_veldt | I'm guesing most of the time there anre't very many trying to eat at the same meal | 20:07 |
| tansell | gau_veldt, you know how many transactions are going on in some bank accounts? | 20:08 |
| tansell | it's of the order of 10,000 per minute | 20:08 |
| tansell | easily | 20:08 |
| gau_veldt | for trading/investment accounts I'm guessing | 20:09 |
| gau_veldt | or really large businesses who settle their purhcases instantly rather than daily | 20:09 |
| gau_veldt | that's still less than 1 per millisecond tho and a millisecond is a long time for a computer | 20:14 |
| gau_veldt | any one transaction typically probably being in the order of microseconds | 20:14 |
| gau_veldt | it'll be the communication medium that makes the chronology of the transactions unpredictable | 20:16 |
| *** zzorn has quit IRC | 21:14 | |
| tansell | brb | 21:35 |
| *** zzorn has joined #tp | 21:37 | |
| *** tansell has quit IRC | 21:38 | |
| *** bddebian has quit IRC | 23:08 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!