Writing by corra on Monday, 31 of March , 2008 at 10:24 am
Sono rientrato oggi dopo una settimana di vacanzina al lago.
Ne ho approfittato per visitare qualche posticino in zona dove non ero mai stato:
- Gandria: paesino adagiato sul lago di Lugano dove abbiamo mangiato una succelenta polenta con capretto su una incantevole terrazza vista lago
- monte Brè: montagnetta che sovrasta Lugano la cui vetta è raggiungibile con una simpatica funicolare e dalla quale si gode un bel panorama sul lago e i monti circostanti
- Monteviasco: unico paesino della provincia di Varese non raggiunto da alcuna strada carrozzabile. Unici modi per arrivarci sono la funivia o una mulattiera di oltre 1500 gradoni in mezzo al bosco. Regna lassù un silenzio irreale. Pranzo a base di salumi locali, polenta e cinghiale e un delicatissimo gelato di capra. Incantevole.
Writing by corra on Monday, 31 of March , 2008 at 10:18 am
Potrebbe lasciare un po’ il tempo che trova ma alle prossime elezioni il sito www.voisietequi.it mi suggerisce di votare il partito socialista. Mah.
Writing by corra on Thursday, 13 of March , 2008 at 2:24 pm
In MySQL 5.1 Cluster Certification Study Guide at page 151 there’s the following sentence: “InnoDB operates with the REPEATABLE READ isolation level, which still allows phantom reads but suppresses non-repeatable reads”.
The sentence is wrong: the REPEATABLE READ isolation level for InnoDB engine doesn’t allow phantom reads.
In some database systems, REPEATABLE READ isolation level allows phantoms, such that if another transaction inserts new rows in the interval between the SELECT statements, the second SELECT will see them. This is not true for InnoDB; phantoms do not occur for the REPEATABLE READ level. SERIALIZABLE isolation level is similar to REPEATABLE READ with the additional restriction that rows selected by one transaction cannot be changed by another until the first transaction finishes. (as stated by MySQL 5 Certification Guide)
Here is an example to demonstrate such a behaviour.
To distinguish two different sessions I use two different prompts: s1> and s2> setting the mysql’s PROMPT statement.
Create a table on s1 and disable autocommit mode to begin a new transaction:
mysql> prompt s1>
PROMPT set to 's1> '
s1>
s1> create table t_idb( id int) engine=innodb;
Query OK, 0 rows affected (0.10 sec)
s1> set autocommit=OFF;
Query OK, 0 rows affected (0.00 sec)
Disable autocommit mode on s2 too to begin a new transaction
mysql> prompt s2>
PROMPT set to 's2> '
s2> set autocommit=OFF;
Query OK, 0 rows affected (0.00 sec)
Insert some values on s1
s1> insert into t_idb values(1);
Query OK, 1 row affected (0.00 sec)
s1> insert into t_idb values(2);
Query OK, 1 row affected (0.00 sec)
Now, on s2 we won’t be able to see these values because s1 is still in the middle of the transaction (not yet committed). For example, this wouldn’t be true in the case of READ UNCOMMITTED mode.
s2> select * from t_idb;
Empty set (0.00 sec)
Now, we commit the transaction on s1.
s1> commit;
Query OK, 0 rows affected (0.01 sec)
Read again the table on s2.
s2> select * from t_idb;
Empty set (0.00 sec)
s2 is still in the middle of his transaction and thus it doesn’t see committed inserts by the another one. This is in contrast with the sentence on the Cluster guide.
s2 will be able to see the values inserted by s1 only after his transaction will be finished (committed or rollbacked)
s2> commit;
Query OK, 0 rows affected (0.00 sec)
s2> select * from t_idb;
+------+
| id |
+------+
| 1 |
| 2 |
+------+
2 rows in set (0.00 sec)
Writing by corra on Tuesday, 11 of March , 2008 at 1:11 pm
Finalmente il tran-tran del centenario è passato. Stiamo pian pianino tornando alla normalità (se così si può dire), anche se stasera c’è Inter-Liverpool … e comunque vada sarà un delirio.
Sabato sera sono andato in piazza Duomo con la famiglia; salito sul palco con Gabriele ho mangiato una fetta di torta. Migliaia i tifosi presenti, è stato un momento emozionante.
