Re: EJB w/ different DB's
I assume you didn't read my earlier discussion as to why MySQL is more or less always a bad idea? Yes I did. And as you said, its _more or less_ always a bad idea. There is always those freaky project with extremely temporary data, low budget, prototyping or something else that could make these systems an option.
Re: EJB w/ different DB's
On Mon, 10 Jan 2000, Magnus Rydin wrote: But if your system does not need this (now or in the future), Databasesystems like MySQL is excellent. Under what cicumstances is mysql better than one of the four? Or even PostgreSQL? _like_ MySQL :) That is small, cheap, and fast on fairly simple types of DBs. I assume you didn't read my earlier discussion as to why MySQL is more or less always a bad idea?
Re: EJB w/ different DB's
On Fri, 7 Jan 2000, Magnus Rydin wrote: Foreign keys are good for making sure your data is consistant, for example you cant reference a bank account that does not exist. They are also good for defining delete rules, such as if this order is deleted, make sure all orderrows are deleted too. Correctly defined, they also speed up searching over multiple tables (if needed). That reminds me of another important feature that mysql is lacking: Constraints. But if your system does not need this (now or in the future), Databasesystems like MySQL is excellent. Under what cicumstances is mysql better than one of the four? Or even PostgreSQL?
RE: EJB w/ different DB's
On Wed, 5 Jan 2000, Kucera, Rich wrote: Isn't container-managed transactions the point of EJBs anyway? So database transaction facilities are no longer mission critical? Or am I missing something... Yes, No. Container-managed transactions are a big point of using EJB's. But what transaction facility do you think the EJB server uses to implement transaction safetyp? You guessed it, transactions in the RDBMS. MySQL also contains some pretty practical advice regarding the indiscriminate use of foriegn keys (it even says they're only useful for visual design tools so designers can more easily generate excess complexity or something to that effect) Well, reading the web site gives me a lot of hype and poor explanations on the lack of transactions. It reminds me a lot about Microsoft marketing tactics and FUD. If it's something they don't implement, it has to suck. Right? They also have a number of banchmark comparison. But all you get is a the speed of simple select and updates. Nothing more complex because mysql performance takes big dive as soon as you bring locking into the picture. /E.
RE: EJB w/ different DB's
On Wed, 5 Jan 2000, Kucera, Rich wrote: Where's the beef in EJB anyway? I thought we had a transactional layer in middleware with ejb... datasources wouldn't necessarily need to be transactional themselves (they wouldn't need to be full-blown databases). You can't do it. In the end there has to be some kind of atomic transactions in the database otherwise you might get inconsistent data if the container crashes. This is a very important point. I noticed that the mysql site now lists transactions as the number one feature to implement. However, they still mentions "transactions will rollback" in the section "things we don't have any plans of implementing". Watch out for that. Their "transactions" will most certainly just be a wrapper around the lock/unlock tables mechanism. This will just provide protection from race condifitions when several connections access the database as the same time, it does not guarantee data integrity if a client crashes. Or the server crashes, for that matter. So if you want to guarantee transaction integrity using mysql you have to reload the backups every time a client or the server has crashed. This means that you will lose data because there is no transaction log to rollback efter the backup has been reloaded. In my opinion, doing this is much more expensive than getting a real database. /E.
Re: EJB w/ different DB's
Foreign keys are good for making sure your data is consistant, for example you cant reference a bank account that does not exist. They are also good for defining delete rules, such as if this order is deleted, make sure all orderrows are deleted too. Correctly defined, they also speed up searching over multiple tables (if needed). But if your system does not need this (now or in the future), Databasesystems like MySQL is excellent. WR "Kucera, Rich" wrote: MySQL also contains some pretty practical advice regarding the indiscriminate use of foriegn keys (it even says they're only useful for visual design tools so designers can more easily generate excess complexity or something to that effect)
RE: EJB w/ different DB's
Isn't container-managed transactions the point of EJBs anyway? So database transaction facilities are no longer mission critical? Or am I missing something... MySQL also contains some pretty practical advice regarding the indiscriminate use of foriegn keys (it even says they're only useful for visual design tools so designers can more easily generate excess complexity or something to that effect) -Original Message- From: Elias Martensson [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, January 04, 2000 7:13 PM To: Orion-Interest Cc: Orion-Interest Subject: Re: EJB w/ different DB's On Tue, 4 Jan 2000, Brien Voorhees wrote: From: "Frank Apap" [EMAIL PROTECTED] I am currently using hSql for my db with my ejb operations, but I want to switch over to a more reliable and documented db. Does anyone have any recommendations for simply but reliable database that will be easy to switch to? I don't know if it integrates specifically with EJB but you might want to check out MySql. It runs on lots of different platforms and is one of the most popular free databases in use. I've been using it for development recently and found it to be extremely fast, easy to setup, and fairly rich in features. I'm not sure but I think it's Open Source, as well. You can check it out at www.mysql.com. O'Reilly has a book that covers MySQL called "MySQL mSQL". It's available at BookPool, which has really good prices on technical books http://www.bookpool.com/.x/nt696p9rmi/sm/1565924347 . I would definately recommend against MySql, it is missing several important features of which the most important one in transactions (in fact, I find it unbeliavble how a database that is missing such an important feature can be so popular). Missing transactions cause a lot of problems, but one of the grat ones is that it is impossible to take a backup of the database and be sure that you are able to restore it in a consitent state (I can discuss the numerous race conditions that can occur off this list if anyone is interested). Also, if the client crashes during a transaction you only know one this: That the database might be in an inconsistent state. There are other features that MySql lacks that at least I find to be equally important: o Views o Stored procedures o Subqueries o Row level locking The last one deserves a bit of exmplanation. It has to do with the fact that since it doesnt have transactions, it has to solve concurrecy issues in a different way. The solution takes by mysql is to create a command called "lock tables" that can lock one or more tables for exclusive access. While tables are locked no otherthread can access that table at the same time. The problem is that the whole table is locked. So if you have a large table of say 100K rows it means that each and every one of those 100K rows are locked when you do somehting to the table. Needless to say, that is very bad for performance. Another really annoying misfeature of mysql is that you cannot create indexes on VARCHAR columns. I assume you can figure out for yourself what this does to either performance or storage space required. Yes, you have propably guessed it. I have been burned by mysql. It took several weeks of screaming until I decided to ditch it. I'm very happy that I did and I'm writing this rant in order to prevent others from falling into the same trap. What should you use instead then? Well, I'd suggest any one of the Four Great ones: Oracle, Sybase, Informix or DB/2. From what I have been told DB/2 offers the best performance of any SQL RDBMS out there. At least that's the one with the best TPC score (at least on Solaris). The only ones out of the above 4 I have tested is Oracle and Sybase. My personal favourtite is Sybase, but that's just because that's the one I know best. Sybase 11.0 is free for all use (including commercial), the latest version, 11.9, is free for non-commercial use. The other 3 are also free for non-commercial use but I haven't checked their licenses in any detail so I guess you'll have to verify for yourselves. If for some reason you feel that you need a SQL RDBMS with source code (I can't understand why because the 4 I mentioned above are magnitudes better than the open sourced ones) then you can use PostgreSQL. I can't vouch for its performance but at least it has most features one needs, including transactions. And a final word, is mysql totally useless? In my opinion, yes. In others, no. The good arguments for the use of mysql that I have heard have been situations where all you do with the tables are individual select's and insert's. I would not classify EJB usage as siple inserts and selects. Especially once you want to use the transaction features of the EJB's. /E.
RE: EJB w/ different DB's
Isn't container-managed transactions the point of EJBs anyway? So database transaction facilities are no longer mission critical? Or am I missing something... I believe that the EJB container always relies on the database to supply the transactional capability. If you use MySQL with EJB in a transactional context, that would be equivalent to turning auto-commit off -- it won't work. Consider what the alternative to this would be -- the container would have to interpose itself as a transitional transactional database between itself and arbitrary data stores. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
Re: EJB w/ different DB's
"Kucera, Rich" wrote: Isn't container-managed transactions the point of EJBs anyway? So database transaction facilities are no longer mission critical? Or am I missing something... you are. there's no point in container-managing transactions if your datasources are non-transactional. there's simply nothing to manage ;-). regards, robert MySQL also contains some pretty practical advice regarding the indiscriminate use of foriegn keys (it even says they're only useful for visual design tools so designers can more easily generate excess complexity or something to that effect) -- (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: EJB w/ different DB's
From: Robert Krüger [SMTP:[EMAIL PROTECTED]] "Kucera, Rich" wrote: Isn't container-managed transactions the point of EJBs anyway? So database transaction facilities are no longer mission critical? Or am I missing something... you are. there's no point in container-managing transactions if your datasources are non-transactional. there's simply nothing to manage ;-). regards, robert Ok, but the container implements the 2-phase logic, right? Where's the beef in EJB anyway? I thought we had a transactional layer in middleware with ejb... datasources wouldn't necessarily need to be transactional themselves (they wouldn't need to be full-blown databases).
EJB w/ different DB's
I am currently using hSql for my db with my ejb operations, but I want to switch over to a more reliable and documented db. Does anyone have any recommendations for simply but reliable database that will be easy to switch to?
Re: EJB w/ different DB's
From: "Frank Apap" [EMAIL PROTECTED] I am currently using hSql for my db with my ejb operations, but I want to switch over to a more reliable and documented db. Does anyone have any recommendations for simply but reliable database that will be easy to switch to? I don't know if it integrates specifically with EJB but you might want to check out MySql. It runs on lots of different platforms and is one of the most popular free databases in use. I've been using it for development recently and found it to be extremely fast, easy to setup, and fairly rich in features. I'm not sure but I think it's Open Source, as well. You can check it out at www.mysql.com. O'Reilly has a book that covers MySQL called "MySQL mSQL". It's available at BookPool, which has really good prices on technical books http://www.bookpool.com/.x/nt696p9rmi/sm/1565924347 . Hope that helps Brien Voorhees
Re: EJB w/ different DB's
I use and enjoy MySQL. However, in EJB work, you may need or want a dbms that supports transactions. PostgreSQL is an full-featured open-source alternative. Other databases that can be used more or less for free include DBMaker (you need to buy a license if you want more than four concurrent connections), and I see that Borland/Inprise has just gone open source with InterBase. --- Brien Voorhees [EMAIL PROTECTED] wrote: From: "Frank Apap" [EMAIL PROTECTED] I am currently using hSql for my db with my ejb operations, but I want to switch over to a more reliable and documented db. Does anyone have any recommendations for simply but reliable database that will be easy to switch to? I don't know if it integrates specifically with EJB but you might want to check out MySql. It runs on lots of different platforms and is one of the most popular free databases in use. I've been using it for development recently and found it to be extremely fast, easy to setup, and fairly rich in features. I'm not sure but I think it's Open Source, as well. You can check it out at www.mysql.com. O'Reilly has a book that covers MySQL called "MySQL mSQL". It's available at BookPool, which has really good prices on technical books http://www.bookpool.com/.x/nt696p9rmi/sm/1565924347 . Hope that helps Brien Voorhees __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
RE: EJB w/ different DB's
Hi Frank, Another Java database on my list is InstantDB, (www.instantdb.co.uk). It's not opensource, but it is free for non-commercial use. Kind Regards, Neville Burnell Business Manager Software -Original Message- From: Frank Apap [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 5 January 2000 8:03 AM To: Orion-Interest Subject: EJB w/ different DB's I am currently using hSql for my db with my ejb operations, but I want to switch over to a more reliable and documented db. Does anyone have any recommendations for simply but reliable database that will be easy to switch to?
Re: EJB w/ different DB's
On Tue, 4 Jan 2000, Brien Voorhees wrote: From: "Frank Apap" [EMAIL PROTECTED] I am currently using hSql for my db with my ejb operations, but I want to switch over to a more reliable and documented db. Does anyone have any recommendations for simply but reliable database that will be easy to switch to? I don't know if it integrates specifically with EJB but you might want to check out MySql. It runs on lots of different platforms and is one of the most popular free databases in use. I've been using it for development recently and found it to be extremely fast, easy to setup, and fairly rich in features. I'm not sure but I think it's Open Source, as well. You can check it out at www.mysql.com. O'Reilly has a book that covers MySQL called "MySQL mSQL". It's available at BookPool, which has really good prices on technical books http://www.bookpool.com/.x/nt696p9rmi/sm/1565924347 . I would definately recommend against MySql, it is missing several important features of which the most important one in transactions (in fact, I find it unbeliavble how a database that is missing such an important feature can be so popular). Missing transactions cause a lot of problems, but one of the grat ones is that it is impossible to take a backup of the database and be sure that you are able to restore it in a consitent state (I can discuss the numerous race conditions that can occur off this list if anyone is interested). Also, if the client crashes during a transaction you only know one this: That the database might be in an inconsistent state. There are other features that MySql lacks that at least I find to be equally important: o Views o Stored procedures o Subqueries o Row level locking The last one deserves a bit of exmplanation. It has to do with the fact that since it doesnt have transactions, it has to solve concurrecy issues in a different way. The solution takes by mysql is to create a command called "lock tables" that can lock one or more tables for exclusive access. While tables are locked no otherthread can access that table at the same time. The problem is that the whole table is locked. So if you have a large table of say 100K rows it means that each and every one of those 100K rows are locked when you do somehting to the table. Needless to say, that is very bad for performance. Another really annoying misfeature of mysql is that you cannot create indexes on VARCHAR columns. I assume you can figure out for yourself what this does to either performance or storage space required. Yes, you have propably guessed it. I have been burned by mysql. It took several weeks of screaming until I decided to ditch it. I'm very happy that I did and I'm writing this rant in order to prevent others from falling into the same trap. What should you use instead then? Well, I'd suggest any one of the Four Great ones: Oracle, Sybase, Informix or DB/2. From what I have been told DB/2 offers the best performance of any SQL RDBMS out there. At least that's the one with the best TPC score (at least on Solaris). The only ones out of the above 4 I have tested is Oracle and Sybase. My personal favourtite is Sybase, but that's just because that's the one I know best. Sybase 11.0 is free for all use (including commercial), the latest version, 11.9, is free for non-commercial use. The other 3 are also free for non-commercial use but I haven't checked their licenses in any detail so I guess you'll have to verify for yourselves. If for some reason you feel that you need a SQL RDBMS with source code (I can't understand why because the 4 I mentioned above are magnitudes better than the open sourced ones) then you can use PostgreSQL. I can't vouch for its performance but at least it has most features one needs, including transactions. And a final word, is mysql totally useless? In my opinion, yes. In others, no. The good arguments for the use of mysql that I have heard have been situations where all you do with the tables are individual select's and insert's. I would not classify EJB usage as siple inserts and selects. Especially once you want to use the transaction features of the EJB's. /E.
