Strange, seems that you can turn of commit conflicts for dirty reads. This is actually READ_COMMITTED behavior. Cool. This DB seem cool. Wonder how well it works.
> -----Original Message----- > From: Bill Burke [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 29, 2003 3:00 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] hsqldb options > > > Too many writes, to many Optimistic exceptions. > TRANSACTION_SERIALIZABLE usually is considered a performance > bottleneck in the same way that our QueuedPessismistic Entity > bean lock can be a bottleneck as well. I would like to try out > ECPERF with Mckoi to see what kind of performance boost we could get. > > Bill > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Sacha > > Labourey > > Sent: Saturday, March 29, 2003 1:09 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] hsqldb options > > > > > > Did you take a look at McKoi? http://www.mckoi.com/database/ > > > > >From the DOC: > > ============= > > There are four transaction isolation levels defined by the SQL standard. > > Each isolation level provides varying degrees of protection from seeing > > changes made by concurrent connections. The Mckoi database > engine supports > > the strongest isolation level defined by the standard - > > TRANSACTION_SERIALIZABLE. This isolation level prevents a > transaction from > > seeing all types of concurrent changes. The Mckoi database > engine achieves > > this through a multi-version data model that efficiently manages and > > isolates multiple views of the underlying data. > > > > During a transaction the connection sees a version (or snapshot) of the > > database that is isolated from any changes made by other connections. > > Additionally, any changes made within the context of a transaction are > > isolated from the rest of the database. This means that while a > > transaction > > is open the view a connection has of the database is blind from > > changes made > > by other concurrent connections. > > > > The multi-version data model allows the Mckoi database engine > to avoid all > > inter-transactional table/row locking and deadlock issues. No > > tables or rows > > are locked between concurrent transactions. While one transaction > > is reading > > from a table, another transaction may update the table at the > > same time. Any > > data consistency conflicts (for example, two connections > > committing a change > > that deletes the same row from a table) are detected when a > transaction is > > committed. > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On > > > Behalf Of Bill Burke > > > Sent: samedi, 29. mars 2003 19:00 > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] hsqldb options > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > > > Behalf Of David > > > > Jencks > > > > Sent: Saturday, March 29, 2003 10:55 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [JBoss-dev] hsqldb options > > > > > > > > > > > > Prompted by a customer, I did some experiments with hsqldb options. > > > > > > > > Currently we specify a tcp port and require a hsqldb mbean > > > to start the > > > > hsqldb server. This opens a port and requires explicit > > > hsqldb shutdown. > > > > > > > > Two other options that appear to work are: > > > > > > > > specify url jdbc:hsqldb:. and remove the hsqldb mbean. > > > This results in a > > > > totally in memory db, nothing saved to disk. IMO this is > > > appropriate for > > > > most of the testsuite since it eliminates problems with > > > data not being > > > > cleaned up between test runs. > > > > > > > > specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. > > > > This results > > > > in the db saved in a couple of files named like somefile. > > > No port is > > > > opened. No explicit shutdown of hsqldb seems to be > > > required (although I > > > > didn't test how much data is actually saved) > > > > > > > > Could someone who knows more about hsqldb please explain > > > clearly why we > > > > would want to continue using the setup we have now rather > > > than one of the > > > > tcp-port free options? > > > > > > > > > > > > > Man, if only hsqldb was transactional. We should recruit > > > them to become a > > > JBoss project and put keen transactional minds like David > > > Jencks on the > > > subject. A fully transactional in-memory DBMS would kick the > > > crap out of > > > everybody in benchmarking. I'm surprise Oracle 9iAS doesn't > > > run in-process > > > with the Oracle DBMS already.... > > > > > > Bill > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: > > > The Definitive IT and Networking Event. Be There! > > > NetWorld+Interop Las Vegas 2003 -- Register today! > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > > _______________________________________________ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: > > The Definitive IT and Networking Event. Be There! > > NetWorld+Interop Las Vegas 2003 -- Register today! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
