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
