Showing entries 1 to 4
Displaying posts with tag: concurrent (reset)
451 CAOS Links 2011.07.29

Open Cloud Initiative launches. HP joins OpenStack. Oracle releases Java 7. And more.

# The Open Cloud Initiative launched to drive open standards in cloud computing.

# HP announced its support for OpenStack.

# Oracle announced the availability of Java SE 7. The Apache Software Foundation warned of index corruption and crashes in Apache Lucene and Solr.

# Nebula …

[Read more]
451 CAOS Links 2010.06.29

Elephants on parade: Hadoop goes mainstream. And more.

Follow 451 CAOS Links live @caostheory on Twitter and Identi.ca
“Tracking the open source news wires, so you don’t have to.”

Elephants on parade
# Cloudera launched v3 of its Distribution for Hadoop and released v1 of Cloudera Enterprise.

# Karmasphere released new Professional and Analyst Editions of its Hadoop development and deployment studio.

# Talend announced that its Integration Suite now offers native support for Hadoop.

# Yahoo …

[Read more]
451 CAOS Links 2008.12.02

MySQL 5.1 reaches GA. But is it ready for production deployments? SpringSource launches commercial version of Apache Tomcat. BusinessWeek focuses on open source business models and open source in the downturn. And more.

Official announcements
MySQL 5.1 Downloads — Generally Available (GA) release for production use Sun Microsystems

SpringSource Launches tc Server; Continues to Redefine Application Server Market SpringSource

Open Solutions Alliance Appoints New President, Announces New Leadership Team Open Solutions Alliance

[Read more]
Statement-based replication is disabled for Falcon

Contrary to what I said earlier, Falcon has decided to deliberately disable statement-based replication using the same capabilities mechanism that InnoDB uses.

The reason is that isolation between concurrent transactions cannot be guaranteed, meaning that two concurrent transactions are not guaranteed to be serializable (the result of a concurrent transaction that has committed can "leak" into an ongoing transaction). Since they are not serializable, it means they cannot be written to the binary log in an order that produce the same result on the slave as on the master.

However, when using row-based replication they are serializable, because whatever values are written to the tables are also written to the binary log, so if data "leaks" into an ongoing transaction, this is what is written to the binary log as …

[Read more]
Showing entries 1 to 4