RE: [JBoss-dev] hsqldb options
Don't worry if you don't understand Peter's posts, it is like American music for French people: just something you have to listen and enjoy, without understanding the words. Peter is somehow jboss-dev's official poet. Make... letters play and ! Ho here a dot playing with a ^column. Klafuti, Klafuta. Pudding song. -- I know who is Zahid Ramman > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Burke > Sent: lundi, 31. mars 2003 17:49 > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] hsqldb options > > > Sorry Peter, no offesne, but > > But could somebody explain what the hell he just posted? > > Sacha, pointed out McKoi. I'd like to see how good of a DB this is. > Anybody have any experience with it? > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > Behalf Of Peter > > Fagerlund > > Sent: Sunday, March 30, 2003 6:29 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] hsqldb options > > > > > > > > söndagen den 30 mars 2003 kl 20.33 skrev marc fleury: > > > > > why don't we bring them on then? > > > > Send in another X number troops to fix the non result .. > > > > Pulezzze what is the non result U are experiencing ... the > real or the > > non-real ... and You say solve it with numbers -hehe ... > > > > You are such a non-general You are ... just a trooper ... U are ... > > > > Listen kids ... producing LOC is very un-interesting - Reducing LOC > > with clear "spell" is productive ... Some of You are just adding > > classes and LOC without keeping a entropy check ... for Your code -- > > shining U are with LOC count. This is very much real here > ... I like a > > iteration of min 1k for a deploy/undeploy repeted test for > thejbossteam > > ploy deploy ... resulting in a non mem fatigue - then thejbossteam > > might be considered to move on ... !!! > > > > check ... > > > > > > --- > > 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: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] hsqldb options
I had a dream! That one day, babelfish will be able to understand AND TRANSLATE Peter songs. Nice try Adrian, but you've abandonned on the last part! ;) > like a > > > iteration of min 1k for a deploy/undeploy repeted test > for thejbossteam > > > ploy deploy ... resulting in a non mem fatigue - then thejbossteam > > > might be considered to move on ... !!! > > There is a memory leak in hot deployment? --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] hsqldb options
Translated in line, Fagerlund->English Never used Mckoi. From cvs it doesn't look very active (but that might mean it is stable?) and it is all one developer? e.g. http://cvs.mckoi.com/cgi-bin/viewcvs.cgi/mckoi-sql/src/com/mckoi/database/ Regards, Adrian From: "Bill Burke" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> Subject: RE: [JBoss-dev] hsqldb options Date: Mon, 31 Mar 2003 10:49:10 -0500 Sorry Peter, no offesne, but But could somebody explain what the hell he just posted? Sacha, pointed out McKoi. I'd like to see how good of a DB this is. Anybody have any experience with it? Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Peter > Fagerlund > Sent: Sunday, March 30, 2003 6:29 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] hsqldb options > > > > söndagen den 30 mars 2003 kl 20.33 skrev marc fleury: > > > why don't we bring them on then? > > Send in another X number troops to fix the non result .. > > Pulezzze what is the non result U are experiencing ... the real or the > non-real ... and You say solve it with numbers -hehe ... > > You are such a non-general You are ... just a trooper ... U are ... You don't fix a problem by throwing more people at it. > > Listen kids ... producing LOC is very un-interesting - Reducing LOC > with clear "spell" is productive ... Some of You are just adding > classes and LOC without keeping a entropy check ... for Your code -- > shining U are with LOC count. This is very much real here ... I We are just adding more code, increasing the entropy (untidiness - the number of possible states of the system) and LOC (lines of code). like a > iteration of min 1k for a deploy/undeploy repeted test for thejbossteam > ploy deploy ... resulting in a non mem fatigue - then thejbossteam > might be considered to move on ... !!! There is a memory leak in hot deployment? > > check ... > > > --- > 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: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] hsqldb options
Sorry Peter, no offesne, but But could somebody explain what the hell he just posted? Sacha, pointed out McKoi. I'd like to see how good of a DB this is. Anybody have any experience with it? Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Peter > Fagerlund > Sent: Sunday, March 30, 2003 6:29 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] hsqldb options > > > > söndagen den 30 mars 2003 kl 20.33 skrev marc fleury: > > > why don't we bring them on then? > > Send in another X number troops to fix the non result .. > > Pulezzze what is the non result U are experiencing ... the real or the > non-real ... and You say solve it with numbers -hehe ... > > You are such a non-general You are ... just a trooper ... U are ... > > Listen kids ... producing LOC is very un-interesting - Reducing LOC > with clear "spell" is productive ... Some of You are just adding > classes and LOC without keeping a entropy check ... for Your code -- > shining U are with LOC count. This is very much real here ... I like a > iteration of min 1k for a deploy/undeploy repeted test for thejbossteam > ploy deploy ... resulting in a non mem fatigue - then thejbossteam > might be considered to move on ... !!! > > check ... > > > --- > 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: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] hsqldb options
söndagen den 30 mars 2003 kl 20.33 skrev marc fleury: why don't we bring them on then? Send in another X number troops to fix the non result .. Pulezzze what is the non result U are experiencing ... the real or the non-real ... and You say solve it with numbers -hehe ... You are such a non-general You are ... just a trooper ... U are ... Listen kids ... producing LOC is very un-interesting - Reducing LOC with clear "spell" is productive ... Some of You are just adding classes and LOC without keeping a entropy check ... for Your code -- shining U are with LOC count. This is very much real here ... I like a iteration of min 1k for a deploy/undeploy repeted test for thejbossteam ploy deploy ... resulting in a non mem fatigue - then thejbossteam might be considered to move on ... !!! check ... --- 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
RE: [JBoss-dev] hsqldb options
why don't we bring them on then? marcf > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Burke > Sent: Saturday, March 29, 2003 1:00 PM > 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
Re: [JBoss-dev] hsqldb options
lördagen den 29 mars 2003 kl 18.54 skrev Sacha Labourey: Well, for quick prototyping it is nice to use the persistent version which allows to use JBossMQ for example and restart JBoss without loosing persistent messages. Yes when You want to prototype a remote DB for some reason, the legacy start of a org.hsqldb.Server is quick. For running testsuites or using a "sql-cashe" the recommended way is to start the Hypesonic mbean with the "Persist = false" flag, that will yield a non-network hsqldb instance. That is about 300% faster then a legacy networked instance. Read the Change note [ 636781 ] hsqldb configuration v 1.7.1 here : http://sourceforge.net/tracker/ index.php?func=detail&aid=636781&group_id=22866&atid=381174 Many moons ago Richard punched out a sample mbean for a thirdparty lib - that has resulted in the hsqldb legacy mbean with funky lingering threads holding on to sockets ... Other then that the Hypersonic mbean also let us use the Hypersonic DatabaseManager in a easy fashion - needed when running as "Persist = false" since that instance is not visible outside of the VM. The natural way is for the hsqldb team to make a JMX distro - and I understand they are working on the DatabaseManager to become a jmx component - discussion here : http://sourceforge.net/forum/forum.php?thread_id=817198&forum_id=73673 Also it has been expressed, some directions toward a JMX HSQLDB, for us and others to use. /peter_f --- 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
RE: [JBoss-dev] hsqldb options
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 > > >
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 toda
Re: [JBoss-dev] hsqldb options
Thinking more about this, the default config should continue to be the file based persistence version since that is what users may already be using for a persistent store across server restarts. If you want a change in this behavior you need to change the hsqldb jca setup. Just document it in the configs so its easy to do. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 29, 2003 9:44 AM Subject: Re: [JBoss-dev] hsqldb options > There is no reason why we can't just document both configs and let the user > choose what they want. The pure in memory version seems like the better > default configuration. > --- 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
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
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
RE: [JBoss-dev] hsqldb options
Well, for quick prototyping it is nice to use the persistent version which allows to use JBossMQ for example and restart JBoss without loosing persistent messages. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Scott M Stark > Sent: samedi, 29. mars 2003 18:45 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] hsqldb options > > > There is no reason why we can't just document both configs > and let the user > choose what they want. The pure in memory version seems like > the better > default configuration. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, March 29, 2003 7:55 AM > 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? > > > > Thanks > > david jencks > > > > --- > 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
Re: [JBoss-dev] hsqldb options
There is no reason why we can't just document both configs and let the user choose what they want. The pure in memory version seems like the better default configuration. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 29, 2003 7:55 AM 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? > > Thanks > david jencks --- 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
Re: [JBoss-dev] hsqldb options
There is no good reason. At 10:55 AM 3/29/03 -0500, you wrote: 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? Thanks david jencks --- 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 LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you --- 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
[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? Thanks david jencks --- 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
