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

Reply via email to