Thread: Fw: Announcing MySQL 5.0 Release Candidate

I tought this could be interesting for PostgreSQL marketing. It's about the
upcoming MySQL 5.0 release. They have done quite a bit to make MySQL more
standards compliant (see "SQL strict mode") -- probably requested by anyone
migrating from a real but more expensive DBMS.

They also claim "XA Distributed Transactions" -- have they implemented
two-phase commit? Nevertheless, this is what we currently have in the
release notes:

> Two-Phase Commit (2PC): long in demand for WAN applications and
> heterogenous data centers using PostgreSQL, this feature allows
> ACID-compliant transactions across widely separated servers.

Perhaps the term "distributed transactions" should be added? Or XA? Those
are probably more buzzword style than two-phase commit.

Best Regards,
Michael Paesold

----- Original Message -----
From: "Kaj Arnö" <kaj@mysql.com>
To: <announce@lists.mysql.com>
Sent: Monday, September 26, 2005 6:41 PM
Subject: Announcing MySQL 5.0 Release Candidate


Dear user of MySQL,

I'm proud and excited to announce the first Release Candidate of MySQL
5.0. This milestone signals that we are nearing what is certainly the
most important release in MySQL's history.

MySQL 5.0 has new functionality that I hope will be welcomed, adopted,
and put to productive use by the community of MySQL users -- you. On the
commercial side, MySQL AB is getting a lot of good vibes from new
enterprise customers who are beginning to understand the impact MySQL
can have on their IT infrastructure and costs of running
mission-critical applications.

The betas of MySQL 5.0 have already been downloaded two million times,
and have thus been tested extensively in a lot of different scenarios.
 From the feedback we get from our community, we know it is already in
production use at numerous sites. Go get your own copy at
http://dev.mysql.com/downloads/mysql/5.0.html

Without question, MySQL 5.0 is the most ambitious release to date for
MySQL AB. Of course, everything we do at MySQL centers around our three
priorities of Performance, Reliability, and Ease of Use.  Version 5.0 of
MySQL is certainly true to these company-wide imperatives.

Key new features of MySQL 5.0 come in three groups:

a) ANSI SQL standard features formerly unknown to MySQL
b) ANSI SQL standard compliance of existing MySQL features
c) New MySQL Storage Engines, Tools and Extensions

The new ANSI SQL features include:

- Views (both read-only and updatable views)
- Stored Procedures and Stored Functions, using the SQL:2003 syntax,
   which is also used by IBM's DB2
- Triggers (row-level)
- Server-side cursors (read-only, non-scrolling)

Implementing ANSI SQL standard ways of using existing MySQL features
means there will be fewer unpleasant surprises ("gotchas") for those
migrating to MySQL from other database systems:

- Strict Mode: MySQL 5.0 adds a mode that complies with standard SQL
   in a number of areas in which earlier versions did not; we now do
   strict data type checking and issue errors for all invalid dates,
   numbers and strings as expected
- INFORMATION_SCHEMA: An ANSI SQL-compliant Data Dictionary for
   accessing metadata, in parallel to the MySQL specific SHOW
   commands
- Precision Math: A new library for fixed-point arithmetic, giving
   high accuracy for financial and mathematical operations
- VARCHAR Data Type: The maximum effective length of a VARCHAR column
   has increased to 65,532 bytes; also, stripping of trailing whitespace
   no longer occurs

New MySQL Storage Engines, Tools and Extensions are:

- XA Distributed Transactions
- ARCHIVE Storage Engine for storing large amounts of data without
   indexes in a very small footprint, intended for historical data that
   may be needed for future audit compliance (Sarbanes Oxley or
   otherwise)
- FEDERATED Storage Engine for accessing data ín tables of remote
   databases rather than in local tables (only in MAX version)
- Instance Manager: a tool to start and stop MySQL Server, even remotely

To find out more details on what's new in MySQL 5.0, follow the pointers
from http://dev.mysql.com/doc/mysql/en/mysql-5-0-nutshell.html

To find out the changes specific to MySQL 5.0.13 in relation to 5.0.12,
see http://dev.mysql.com/doc/mysql/en/news-5-0-13.html

MySQL 5.0 is also reflected in our GUI tools and Connectors:

MySQL Administrator 1.1.3 and MySQL Query Browser 1.1.15 are aware of
the new MySQL 5.0 features, can be used to write and test stored
procedures, create views, include them in scheduled backups and much more.

The latest shipping versions of our Connectors work with MySQL 5.0, and
all connectors (MySQL Connector/ODBC, Connector/J and Connector/NET)
will support all flagship features before 5.0 goes GA.

We're pleased that we've reached a point of stability where it's been a
while since we received a significant inflow of bugs that drastically
impacted a large number of users. Of course, we recognize we haven't
crossed the finish line yet, so we still very much need your involvement
to ensure that MySQL 5.0 is the best that it possibly can be.

With MySQL 5.0 being that stable, I encourage you to do all of your new
database development using MySQL 5.0:

1. Download 5.0 from http://dev.mysql.com/downloads/mysql/5.0.html
2. Use the new features you need
3. Report any issues you find through our bug-reporting system at
    http://bugs.mysql.com/.

To show our appreciation for your efforts, we'll be fixing the bugs you
find as fast as we can.

And, to provide a little extra motivation, we will be giving away Apple
iPod nanos, and even full conference passes to our 2006 MySQL Users
Conference, to those who deliver the most valuable feedback. Read more
on http://dev.mysql.com/mysql_5_contest.html . Without your involvement
and your excellent input, we at MySQL wouldn't be able to do our job: to
produce high-quality database software for you to trust and use.

I look forward to your input

- in our MySQL Forums at http://forums.mysql.com/
- in the bug database at http://bugs.mysql.com/
- in our mailing lists at http://lists.mysql.com/
- in the PlanetMySQL blog aggregation via
   http://www.planetmysql.org/newfeed.php
- in the User Comments of our manual at
   http://dev.mysql.com/doc/mysql/en/index.html
   (specifically for Documentation comments)
- and in the form of downloads from
   http://dev.mysql.com/downloads/mysql/5.0.html

Thank you -- we look forward to hearing back from you -- not just about
bugs but any feedback on how MySQL can help support you.

Kaj Arnö
VP Community Relations
MySQL AB

mpaesold@gmx.at ("Michael Paesold") writes:
>> Two-Phase Commit (2PC): long in demand for WAN applications and
>> heterogenous data centers using PostgreSQL, this feature allows
>> ACID-compliant transactions across widely separated servers.
>
> Perhaps the term "distributed transactions" should be added? Or XA?
> Those are probably more buzzword style than two-phase commit.

No, those would qualify as "lying," which is something that we oughn't
do.  Lying should be left to the advocates of other systems...

Two phase commit is a prerequisite for doing distributed transactions,
and XA is a particular standard to which the 2PC support does not, at
this point, conform.
--
let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;;
http://www.ntlug.org/~cbbrowne/linuxxian.html
"HE'S AHAB, boy; and Ahab of old, thou knowest, was a crowned king!"
-- /Moby-Dick/, Ch 16

Chris Browne wrote:
> Two phase commit is a prerequisite for doing distributed transactions,
> and XA is a particular standard to which the 2PC support does not, at
> this point, conform.

I did not know that, thanks for clarification.

Out of interest, what is still needed to support XA?

Best Regards,
Michael Paesold

Chris,

> Two phase commit is a prerequisite for doing distributed transactions,
> and XA is a particular standard to which the 2PC support does not, at
> this point, conform.

Eh?  I was under the impression that XA was implemented in the JDBC
layer, not in the backend.

--Josh

josh@agliodbs.com (Josh Berkus) writes:
> Chris,
>
>> Two phase commit is a prerequisite for doing distributed transactions,
>> and XA is a particular standard to which the 2PC support does not, at
>> this point, conform.
>
> Eh?  I was under the impression that XA was implemented in the JDBC
> layer, not in the backend.

There was an JDBC-based *attempt* at an XA handler; it wasn't fully
functional, which essentially means it wasn't really XA.

When the 2PC discussion was going on, it definitely came up in the
discussion that this was a prerequisite to doing XA properly.  It
might not be forcibly necessary in the strictest sense, but 2PC is
certainly one of the normal means for synchronizing distributed
transactions...
--
"cbbrowne","@","cbbrowne.com"
http://cbbrowne.com/info/sgml.html
"When people understand what Microsoft is up to, they're outraged."
-- Tim O'Reilly, President, O'Reilly & Associates

Chris,

> There was an JDBC-based *attempt* at an XA handler; it wasn't fully
> functional, which essentially means it wasn't really XA.
>
> When the 2PC discussion was going on, it definitely came up in the
> discussion that this was a prerequisite to doing XA properly.  It
> might not be forcibly necessary in the strictest sense, but 2PC is
> certainly one of the normal means for synchronizing distributed
> transactions...

But ... now that we have 2PC, XA could be implemented through pg-jdbc if
someone wanted to, yes?

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Thu, 29 Sep 2005, Josh Berkus wrote:

> But ... now that we have 2PC, XA could be implemented through pg-jdbc if
> someone wanted to, yes?
>

We have patches for xa support pending, but have not committed them yet.
Our 2PC support doesn't allow a full XA implementation because full XA
allows multiple transactions to run in parallel on the same resource and
allows other threads to join an already running transaction.  The
question is whether application servers and transaction managers do
this by default and whether it can be disabled.  Initial research shows
our support may be good enough for practical purposes.

http://archives.postgresql.org/pgsql-jdbc/2005-06/msg00165.php
http://archives.postgresql.org/pgsql-jdbc/2005-06/msg00171.php

Kris Jurka

On Tue, 2005-09-27 at 23:10 -0400, Chris Browne wrote:
> josh@agliodbs.com (Josh Berkus) writes:
> > Chris,
> >
> >> Two phase commit is a prerequisite for doing distributed transactions,
> >> and XA is a particular standard to which the 2PC support does not, at
> >> this point, conform.
> >
> > Eh?  I was under the impression that XA was implemented in the JDBC
> > layer, not in the backend.
>
> There was an JDBC-based *attempt* at an XA handler; it wasn't fully
> functional, which essentially means it wasn't really XA.
>
> When the 2PC discussion was going on, it definitely came up in the
> discussion that this was a prerequisite to doing XA properly.  It
> might not be forcibly necessary in the strictest sense, but 2PC is
> certainly one of the normal means for synchronizing distributed
> transactions...

I didn't realise that the 2PC we have implemented was not XA.

That's bad news. To most people they are the same thing, so I foresee
some fairly poor feedback.

It is my understanding that an XA interface was required to interface
correctly with transaction managers. AFAIK XA is an interface that
JDBC/JTA provides a mapping for, but they are different things.

Who knows the full info on this?

Best Regards, Simon Riggs

>I didn't realise that the 2PC we have implemented was not XA.
>
>That's bad news. To most people they are the same thing, so I foresee
>some fairly poor feedback.
>
>
To most people where? I am not being antagonistic, I am just curious if
this is a Java
community thing or if you impression is "in general" people consider
them the same
thing.

Sincerely,

Joshua D. Drake




--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

simon@2ndquadrant.com (Simon Riggs) writes:

> On Tue, 2005-09-27 at 23:10 -0400, Chris Browne wrote:
>> josh@agliodbs.com (Josh Berkus) writes:
>> > Chris,
>> >
>> >> Two phase commit is a prerequisite for doing distributed transactions,
>> >> and XA is a particular standard to which the 2PC support does not, at
>> >> this point, conform.
>> >
>> > Eh?  I was under the impression that XA was implemented in the JDBC
>> > layer, not in the backend.
>>
>> There was an JDBC-based *attempt* at an XA handler; it wasn't fully
>> functional, which essentially means it wasn't really XA.
>>
>> When the 2PC discussion was going on, it definitely came up in the
>> discussion that this was a prerequisite to doing XA properly.  It
>> might not be forcibly necessary in the strictest sense, but 2PC is
>> certainly one of the normal means for synchronizing distributed
>> transactions...
>
> I didn't realise that the 2PC we have implemented was not XA.
>
> That's bad news. To most people they are the same thing, so I foresee
> some fairly poor feedback.

That seems somewhat silly.

XA is a Well Defined thing that is a whole lot more than just two
phase commit.

<http://www.opengroup.org/public/pubs/catalog/c193.htm>

It is an API specified by an Open Group standard with a 12 function
call API.

Why anyone should _assume_ that something being called 2PC conforms to
a standard with a particular name that isn't being named seems a bit
mystifying.

If it was XA that was being implemented in PostgreSQL 8.2, then it
would be big-time dumb to not mention that.

> It is my understanding that an XA interface was required to interface
> correctly with transaction managers. AFAIK XA is an interface that
> JDBC/JTA provides a mapping for, but they are different things.
>
> Who knows the full info on this?

Having 2 phase commit was to be a _prerequisite_ to implementing an XA
interface.

It looks like the main places where XA is getting used these days is
with Java frameworks.

BEA implemented Tuxedo, which was the basis for XA; these days, what
they are hawking are Java frameworks.
--
output = reverse("moc.enworbbc" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/finances.html
"What if you slept?  And what if, in your sleep, you dreamed?
 And what if, in your dream, you went to heaven and there
 plucked a strange and beautiful flower?  And what if, when
 you awoke, you had the flower in your hand?  Ah, what then?"
    --Coleridge

Hi,

I don't know whether this is the right list to clarify about 2PC & XA,
but here goes...

On Fri, 2005-09-30 at 14:42 -0400, Chris Browne wrote:
> simon@2ndquadrant.com (Simon Riggs) writes:
>
> > On Tue, 2005-09-27 at 23:10 -0400, Chris Browne wrote:
> >> josh@agliodbs.com (Josh Berkus) writes:
> >> > Chris,
> >> >
> >> >> Two phase commit is a prerequisite for doing distributed transactions,
> >> >> and XA is a particular standard to which the 2PC support does not, at
> >> >> this point, conform.
> >> >
> >> > Eh?  I was under the impression that XA was implemented in the JDBC
> >> > layer, not in the backend.
> >>
> >> There was an JDBC-based *attempt* at an XA handler; it wasn't fully
> >> functional, which essentially means it wasn't really XA.
> >>
> >> When the 2PC discussion was going on, it definitely came up in the
> >> discussion that this was a prerequisite to doing XA properly.  It
> >> might not be forcibly necessary in the strictest sense, but 2PC is
> >> certainly one of the normal means for synchronizing distributed
> >> transactions...
> >
> > I didn't realise that the 2PC we have implemented was not XA.
> >
> > That's bad news. To most people they are the same thing, so I foresee
> > some fairly poor feedback.
>
> That seems somewhat silly.
>
> XA is a Well Defined thing that is a whole lot more than just two
> phase commit.
>
> <http://www.opengroup.org/public/pubs/catalog/c193.htm>
>
> It is an API specified by an Open Group standard with a 12 function
> call API.
>
> Why anyone should _assume_ that something being called 2PC conforms to
> a standard with a particular name that isn't being named seems a bit
> mystifying.

I admit my knowledge of database is not very deep, and I thought that
2PC and XA is about the same thing.  But I guess there are many people
having the same thinking as me.

In where I live (Singapore), PostgreSQL is almost unheard of, and I'm
tired of people promoting MySQL for everything from simple website to
full blown ERP system.  Naturally, when I see that MySQL 5.0 is going to
have XA, I'd check out PostgreSQL to see  whether it has distributed
transaction too.  When I see that it has 2PC, I thought it's the same as
XA.

I still don't quite understand the whole thing.  Correct me if I'm
wrong: 2PC is a distributed transaction and a subset of XA's
functionality.  And XA is a standard that is mainly used by Java?  Does
this mean that Java JDBC/JTA can't do a distributed transaction with
postgreSQL for now?

Thanks :)

On Fri, 2005-09-30 at 08:23 -0700, Joshua D. Drake wrote:
> >I didn't realise that the 2PC we have implemented was not XA.
> >
> >That's bad news. To most people they are the same thing, so I foresee
> >some fairly poor feedback.
> >
> >
> To most people where? I am not being antagonistic, I am just curious if
> this is a Java
> community thing or if you impression is "in general" people consider
> them the same
> thing.

Well, for a long time CICS 2PC was not XA. So if you're an IBM
mainframer then you might ask what type of 2PC we support.

Every other conversation I've had on this, XA has been used synonomously
with 2PC. So I mean, in general.

XA predates J2EE and JDBC.

Best Regards, Simon Riggs

Chris Browne wrote:
> It is an API specified by an Open Group standard with a 12 function
> call API.

This may be interesting for those wondering what's going on:

http://java.sun.com/j2se/1.4.2/docs/api/javax/transaction/xa/package-summary.html

So yes, you probably need 2PC support in the server, but the actual
implementation work needs to be done in the JDBC driver (or any other
client interface).

--
Peter Eisentraut
http://developer.postgresql.org/~petere/