RE: [JBoss-dev] hsqldb options

2003-03-31 Thread Bill Burke
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

2003-03-31 Thread Adrian Brock
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

2003-03-31 Thread Sacha Labourey
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

2003-03-31 Thread Sacha Labourey
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

2003-03-30 Thread marc fleury
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

2003-03-30 Thread Peter Fagerlund
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


[JBoss-dev] hsqldb options

2003-03-29 Thread David Jencks
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

2003-03-29 Thread Micael
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


Re: [JBoss-dev] hsqldb options

2003-03-29 Thread Scott M Stark
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

2003-03-29 Thread Bill Burke


 -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

2003-03-29 Thread 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.

 -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

2003-03-29 Thread Sacha Labourey
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

2003-03-29 Thread Scott M Stark
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

2003-03-29 Thread Bill Burke
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

RE: [JBoss-dev] hsqldb options

2003-03-29 Thread Bill Burke
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

Re: [JBoss-dev] hsqldb options

2003-03-29 Thread Peter Fagerlund
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=detailaid=636781group_id=22866atid=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=817198forum_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