Martin Fuchs wrote:
One additional constraint that might help (for JDO apps) would be to
suggest that everyone creates the app using a database that everyone can get - I suggest MySQL. That way, db schemas supplied with competition entries will be easily set up by others without having to rework the SQL and the mapping... or obtain a JDBC driver. People could always supply alternative mappings/schema for their favourite db as well if they want to.
I concur with this suggestion. However, the only way that MySQL can provide transactionality is via the InnoDB table type. So this restriction will need to be for 4.x so that InnoDB tables are enabled AND the default-table-type=InnoDB option is used either in the my.cnf file or on the startup command.
Why not use HSQL as test database? Setting up this database is really very simple, and compatible to any environment, because it is a pure Java solution.
I don't mind using either one. I use all kinds of different databases for development. But if we're going to think about using HSQL, then I think we should definitely consider using Derby.
According to this doc:
http://hsqldb.sourceforge.net/doc/guide/ch02.html#N104D5
the only supported tx isolation level provided by HSQL is TRANSACTION_READ_UNCOMMITTED which only fulfulls the atomicity requirement. This means that dirty, non-repeatable and phantom reads can all take place.
This is in stark contrast to MySQL 4.0.5 and greater using InnoDB which supports all four transaction isolation levels:
http://dev.mysql.com/doc/mysql/en/InnoDB_transaction_isolation.html
Note that the default tx isolation level for MySQL is TRANSATION_REPEATABLE_READ.
As a third choice, I think we should also consider using Derby. Derby is also embeddable like HSQL, is 100% pure Java, but Derby is *far, far* more powerful and supports all tx isolation levels:
http://publibfi.boulder.ibm.com/epubs/html/cloud51/doc/html/coredocs/concept4.htm
We could even provide a pre-packaged template to make it quite easy for users integrating their examples.
As far as a template goes, do we really want to restrict all entries in the contest to a particular set of tables? I don't think I'm in favor of that. However, I am in favor of placing a limit on the size of the application in some way.
Once the dicussion surrounding this topic is satisfied, I'll send out a brand new message proposing a vote on the topic. Until that time, please abstain from voting other than expressing an opinion.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project http://www.castor.org/
Apache Geronimo http://geronimo.apache.org/
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
