Re: HARDWARE FOR J2EE apps
At 06:53 PM 10/12/2000 +0200, you wrote: Hi Kevin, Do you create the database in IBConsole ? Because the ibconsole has an bug when creating databases. If so, you probably have to get the newer version of IBConsole : URL : http://www.interbase.com/open/downloads/ib_download.html goto the miscellaneous section (at the bottumn of the page) and download IBConsole - build 308. You must overwrite the ibconsole in your interbase install directory. If you want the interbase-database-schema.xml (for orion cmp managed persistence) mail me and i will sent it to you. There's also a newer build somewhere on http://community.borland.com/. Its where the author is posting all his updates. Further more i think interbase 6 is an very good database but I would like to know if it handle a large amount of connections at the same time (like 500 or something). There isn't much info about that in the docs. I haven't scaled to that level, but you might want to post to the inprise newsgroups on that, and I bet you'll get a response from someone. HTH, -Mike
RE: HARDWARE FOR J2EE apps
I would reconsider implementing such low-level functionality. the deeper you dig into it, the more little things you will discover that have the potential to break your neck. It's probably not that hard to this stuff up and running. the problem is to get it really stable. we're currently planning on the following setup. 2 rather powerful dual processor machines, that run orion and interbase 6 on linux with heartbeat for ip-address takeover. one is running as a hot standby and they are syncronized using the IBReplicator product that was already mentioned in this thread (http://www.synectics.co.za/). the performance of the syncronization that's described in the docs is enough for our application to believe it will basically be real-time (something like 200 updates per second over a 10Mbit link and pentium 200s). of course this only takes care of availability and doesn't do any load balancing but for us the performance we can achieve by using good caching algorithms at the application level and fast dual processor machines is enough. for a really scalable solution I'd probably look at sybase (the commercial versions, the free version doesn't support clustering). of course, if the database is not the bottleneck one could use the standby solution for the database only and put a real cluster of orion servers in front. robert At 23:37 11.10.00 , you wrote: Hi! On Wed, 11 Oct 2000, Robert Krueger wrote: [description of budget-friendly Orion setup - snip] sounds very nice but what about the database? how do you cluster that without spending an arm and a leg? our experience is, that it's not that hard to set up clustered web services with static pages and servlets but the really expensive part is, when you want that high availability for your database. it doesn't buy you much if you have highly available ejbs when the database server goes down. many people use clustered apache/jserv on linux and cheap pc-hardware for high volume transactional websites but have a large enterprise sun running oracle in the back. anyone out there running a configuration with orion that includes a database with failover that doesn't blow up the budget too much (compared to other components)? Ah. Deja Vu. :-) I'm involved with a startup company here in Sweden, and considering Orion as app server we are also contemplating what non-arm-and-a-leg-spending ways there are to enable a database for failover and load-balancing functionality. We are looking at either PostgreSQL, InterBase, SAP-DB or MySQL (yeah, I know) as our database. We have not seen any currently freely available solutions for failover for either of those (anybody?). So, we are thinking about implementing something by ourselves. Nothing definite so far, but: - The synchronizing of data will be done on the application-level, not by the database servers themselves. See below. - We'll avoid numeric sequences for record keys to make this easier. We will implement some unique key-generation scheme based on whatever is needed to make keys unique but still not rely on strict monotone numeric sequences or similar ( md5(table_name+timestamp()), perhaps? ). - We'll code a DB-abstraction layer that takes care of executing all update queries against all configured database servers and all read queries against one of them known to be alive and lightly loaded (or not recently accessed, or some other scheme). - I guess that if we need database-specific stuff such as stored procedures or similar we need to use the same database software for all failover machines. - If we stay away from database-specifics we could possibly allow failover between different database products. Would be cool. Using straight, standard SQL, could make this feasible. These are very premature thoughts, we are getting closer to the planning and design stage, but we haven't actually started yet. Any thoughts? Ridiculously naive? Or possible to pull off? robert /David Reach me by - Email: [EMAIL PROTECTED], WWW: http://www.dtek.chalmers.se/~d0dak/ - --/David--- (-) 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: HARDWARE FOR J2EE apps
I was wondering whether it would be possible to let the orion server(s) switch datasource as a sort of failover procedure. I haven't digged myself into clustering and failover, but here's the idea. Assuming you have made sure the server are running with failover and you have bought yourself a SCSI-raid configuration with a Y connection (that is the disk are connected to two systems), the largest risk of failure is the database server. If however orion could automatically switch on some sort of connection timeout from one server to another, you can solve this problem almost to easy. This stil leaves you with a number of risks like: - write failure of the db-software corrupting your database. - program logic failures. - site disaster (fire, flooding, tornado etc.). - human error. Depending on the sort system I guess, I could live with that. Frank On Wednesday, October 11, 2000 11:37 PM, David Kinnvall [SMTP:[EMAIL PROTECTED]] wrote: Hi! On Wed, 11 Oct 2000, Robert Krueger wrote: [description of budget-friendly Orion setup - snip] sounds very nice but what about the database? how do you cluster that without spending an arm and a leg? our experience is, that it's not that hard to set up clustered web services with static pages and servlets but the really expensive part is, when you want that high availability for your database. it doesn't buy you much if you have highly available ejbs when the database server goes down. many people use clustered apache/jserv on linux and cheap pc-hardware for high volume transactional websites but have a large enterprise sun running oracle in the back. anyone out there running a configuration with orion that includes a database with failover that doesn't blow up the budget too much (compared to other components)? Ah. Deja Vu. :-) I'm involved with a startup company here in Sweden, and considering Orion as app server we are also contemplating what non-arm-and-a-leg-spending ways there are to enable a database for failover and load-balancing functionality. We are looking at either PostgreSQL, InterBase, SAP-DB or MySQL (yeah, I know) as our database. We have not seen any currently freely available solutions for failover for either of those (anybody?). So, we are thinking about implementing something by ourselves. Nothing definite so far, but: - The synchronizing of data will be done on the application-level, not by the database servers themselves. See below. - We'll avoid numeric sequences for record keys to make this easier. We will implement some unique key-generation scheme based on whatever is needed to make keys unique but still not rely on strict monotone numeric sequences or similar ( md5(table_name+timestamp()), perhaps? ). - We'll code a DB-abstraction layer that takes care of executing all update queries against all configured database servers and all read queries against one of them known to be alive and lightly loaded (or not recently accessed, or some other scheme). - I guess that if we need database-specific stuff such as stored procedures or similar we need to use the same database software for all failover machines. - If we stay away from database-specifics we could possibly allow failover between different database products. Would be cool. Using straight, standard SQL, could make this feasible. These are very premature thoughts, we are getting closer to the planning and design stage, but we haven't actually started yet. Any thoughts? Ridiculously naive? Or possible to pull off? robert /David Reach me by - Email: [EMAIL PROTECTED], WWW: http://www.dtek.chalmers.se/~d0dak/ - --/David---
Re: HARDWARE FOR J2EE apps
Hi Kevin, Do you create the database in IBConsole ? Because the ibconsole has an bug when creating databases. If so, you probably have to get the newer version of IBConsole : URL : http://www.interbase.com/open/downloads/ib_download.html goto the miscellaneous section (at the bottumn of the page) and download IBConsole - build 308. You must overwrite the ibconsole in your interbase install directory. If you want the interbase-database-schema.xml (for orion cmp managed persistence) mail me and i will sent it to you. Further more i think interbase 6 is an very good database but I would like to know if it handle a large amount of connections at the same time (like 500 or something). There isn't much info about that in the docs. Greetings Wim Veninga. "Duffey, Kevin" wrote: Hey Scott, Interbase 6 is pretty nice in my opinion. Its SQL 92 compliant (if that means anything), its completely free and is now open-source, has a type IV jdbc driver, and it has a VERY small foot-print. It runs on most platforms I believe, and thus far its pretty darn fast. However, I have not been able to successfully create a database in it. I keep getting some stupid error when I try to create a database and I can't find any information on it. I'll have to post to the Interbase site probably..or maybe there is a newer version. I wish there was some more detailed info on how to completely set up Interbase. I can however connect via my java app and get connections out. I just can't seem to create tables and what not. Anyways..I worked with Interbase 4 and it was pretty fast, so I am sure 6 is better in many ways (that is not always true..but I hope it is). -Original Message- From: Scott Stirling [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 11, 2000 3:25 PM To: Orion-Interest Subject: RE: HARDWARE FOR J2EE apps Why would you use mySQL over Postgresl? They're both free, but Postgresql has a JDBC driver that's XA-compliant. Also, mySQL is known to blow away your whole database if it has a bad crash, whereas Postgresql is better at persisting data through a bad crash. How does Interbase 6 compare to Postgresql? Is it free? Scott Stirling West Newton, MA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Wednesday, October 11, 2000 4:01 PM To: Orion-Interest Subject: RE: HARDWARE FOR J2EE apps Hi, sounds very nice but what about the database? how do you cluster that without spending an arm and a leg? our experience is, that it's not that hard to set up clustered web services with static pages and servlets but the really expensive part is, when you want that high availability for your database. it doesn't buy you much if you have highly available ejbs when the database server goes down. many people use clustered apache/jserv on linux and cheap pc-hardware for high volume transactional websites but have a large enterprise sun running oracle in the back. anyone out there running a configuration with orion that includes a database with failover that doesn't blow up the budget too much (compared to other components)? Well, to start off with there is mySQL and the one I like the most is Interbase 6..a free powerful RDBMS. However, as far as clustering them..I don't quite know the best way. I would think a load-balancer or a switch or something, would be required. Nobody ever said it was cheap! ;) I used to think $25,000 could easily set up a website from front to back, software, hardware, etc..but not even close these days. If you are just starting out, I would use Orion for front-end and ejb-logic tiers in a clustered environment (for developing/testing), with a single server running mySQL or Interbase for the database. Once you get some funding and move beyond the concept phase, you should put a sizeable chunk to invest in co-locating your site and doing the full load-balancing setup. I would estimate a cheap setup with 2 front-end web/servlet servers failed over, 2 ejb servers, and a database cluster will still run around $100,000, to co-lo it..which is probably the best thing to do to make sure its up 24/7.
RE: HARDWARE FOR J2EE apps
Wim,
We've used IB extensively for the past few years - it's an excellent
low-maintenance choice (DBA-free) for small to medium applications, but
doesn't scale well to large numbers of users or heavy loads. Depending on
the OS platform, there is a hard limit of 250 simultaneous connections - but
we often run into concurrency problems well below that number, even on large
Sun servers.
E-mail me if you need more info,
Steve
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of wim veninga
Sent: 12 October 2000 18:53
To: Orion-Interest
Subject: Re: HARDWARE FOR J2EE apps
Hi Kevin,
Do you create the database in IBConsole ? Because the ibconsole
has an bug when
creating databases.
If so, you probably have to get the newer version of IBConsole :
URL : http://www.interbase.com/open/downloads/ib_download.html
goto the miscellaneous section (at the bottumn of the page) and download
IBConsole - build 308. You must overwrite the ibconsole in your interbase
install directory. If you want the interbase-database-schema.xml
(for orion cmp
managed persistence) mail me and i will sent it to you.
Further more i think interbase 6 is an very good database but I
would like to
know
if it handle a large amount of connections at the same time (like 500 or
something).
There isn't much info about that in the docs.
Greetings Wim Veninga.
"Duffey, Kevin" wrote:
Hey Scott,
Interbase 6 is pretty nice in my opinion. Its SQL 92 compliant (if that
means anything), its completely free and is now open-source,
has a type IV
jdbc driver, and it has a VERY small foot-print. It runs on
most platforms I
believe, and thus far its pretty darn fast. However, I have not
been able to
successfully create a database in it. I keep getting some
stupid error when
I try to create a database and I can't find any information on
it. I'll have
to post to the Interbase site probably..or maybe there is a
newer version. I
wish there was some more detailed info on how to completely set up
Interbase. I can however connect via my java app and get
connections out. I
just can't seem to create tables and what not. Anyways..I worked with
Interbase 4 and it was pretty fast, so I am sure 6 is better in
many ways
(that is not always true..but I hope it is).
-Original Message-
From: Scott Stirling [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 11, 2000 3:25 PM
To: Orion-Interest
Subject: RE: HARDWARE FOR J2EE apps
Why would you use mySQL over Postgresl? They're both free,
but Postgresql has a
JDBC driver that's XA-compliant. Also, mySQL is known to
blow away your whole
database if it has a bad crash, whereas Postgresql is better
at persisting data
through a bad crash.
How does Interbase 6 compare to Postgresql? Is it free?
Scott Stirling
West Newton, MA
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Duffey, Kevin
Sent: Wednesday, October 11, 2000 4:01 PM
To: Orion-Interest
Subject: RE: HARDWARE FOR J2EE apps
Hi,
sounds very nice but what about the database? how do you
cluster that
without spending an arm and a leg? our experience is, that
it's not that
hard to set up clustered web services with static pages and
servlets but
the really expensive part is, when you want that high
availability for your
database. it doesn't buy you much if you have highly
available ejbs when
the database server goes down. many people use clustered
apache/jserv on
linux and cheap pc-hardware for high volume transactional
websites but have
a large enterprise sun running oracle in the back. anyone out
there running
a configuration with orion that includes a database with
failover that
doesn't blow up the budget too much (compared to other
components)?
Well, to start off with there is mySQL and the one I like
the most is
Interbase 6..a free powerful RDBMS. However, as far as
clustering them..I
don't quite know the best way. I would think a
load-balancer or a switch or
something, would be required. Nobody ever said it was
cheap! ;) I used to
think $25,000 could easily set up a website from front to
back, software,
hardware, etc..but not even close these days. If you are
just starting out,
I would use Orion for front-end and ejb-logic tiers in a clustered
environment (for developing/testing), with a single server
running mySQL or
Interbase for the database. Once you get some funding and
move beyond the
concept phase, you should put a sizeable chunk to invest in
co-locating your
site and doing the full load-balancing setup. I would
estimate a cheap setup
with 2 front-end web/servlet servers failed over, 2 ejb
servers, and a
databa
RE: HARDWARE FOR J2EE apps
As far as DB redundancy, I have heard that it is possible to have two boxes using a shared RAID that holds the data. The first box is the primary database, and if that one is down, the second one takes over. The RAID itself taking care of the disk level redundancy, and the two boxes handling the System level redundency. I have never personally tried this, but it sounds intriguing. -Lkb At 04:26 PM 10/11/00 -0700, Duffey, Kevin wrote: Is a veritos cluster expensive? I know we are using that here with Oracle 8i, but I am not sure if that is outrageous in price, and if it works with all db's, or if its specific. Also, does Oracle, IBM DB2, and so on support clustering by themselves..or does it require 3rd party software to make this work? -Original Message- From: David Kinnvall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 11, 2000 2:37 PM To: Orion-Interest Subject: RE: HARDWARE FOR J2EE apps Hi! On Wed, 11 Oct 2000, Robert Krueger wrote: [description of budget-friendly Orion setup - snip] sounds very nice but what about the database? how do you cluster that without spending an arm and a leg? our experience is, that it's not that hard to set up clustered web services with static pages and servlets but the really expensive part is, when you want that high availability for your database. it doesn't buy you much if you have highly available ejbs when the database server goes down. many people use clustered apache/jserv on linux and cheap pc-hardware for high volume transactional websites but have a large enterprise sun running oracle in the back. anyone out there running a configuration with orion that includes a database with failover that doesn't blow up the budget too much (compared to other components)? Ah. Deja Vu. :-) I'm involved with a startup company here in Sweden, and considering Orion as app server we are also contemplating what non-arm-and-a-leg-spending ways there are to enable a database for failover and load-balancing functionality. We are looking at either PostgreSQL, InterBase, SAP-DB or MySQL (yeah, I know) as our database. We have not seen any currently freely available solutions for failover for either of those (anybody?). So, we are thinking about implementing something by ourselves. Nothing definite so far, but: - The synchronizing of data will be done on the application-level, not by the database servers themselves. See below. - We'll avoid numeric sequences for record keys to make this easier. We will implement some unique key-generation scheme based on whatever is needed to make keys unique but still not rely on strict monotone numeric sequences or similar ( md5(table_name+timestamp()), perhaps? ). - We'll code a DB-abstraction layer that takes care of executing all update queries against all configured database servers and all read queries against one of them known to be alive and lightly loaded (or not recently accessed, or some other scheme). - I guess that if we need database-specific stuff such as stored procedures or similar we need to use the same database software for all failover machines. - If we stay away from database-specifics we could possibly allow failover between different database products. Would be cool. Using straight, standard SQL, could make this feasible. These are very premature thoughts, we are getting closer to the planning and design stage, but we haven't actually started yet. Any thoughts? Ridiculously naive? Or possible to pull off? robert /David Reach me by - Email: [EMAIL PROTECTED], WWW: http://www.dtek.chalmers.se/~d0dak/ - --/David-- - /** * @author: Lorin Kobashigawa-Bates [EMAIL PROTECTED] * @title: CodeMonkey / COO - Robot6 Inc. * @phone: 415.345.8872 * @addr: 1177 Polk St. San Francisco, CA 94109 */
RE: HARDWARE FOR J2EE apps
Well, for development, in terms of how fast you want to compile your code, I would go with the fastest PC you can afford. However, I have a PIII650 with 256MB RAM, and 9GB HD that is more than fast enough for development purposes. Unless you plan on playing games, you can probably get a $700 workstation made with oem/generic parts that works fine for development (not including monitor). I would spend the most money on a big monitor, or a nice 19" flat-screen. Go for flat if you can..its easier on the eyes and takes little room, but at 3x+ the cost of a good 19" monitor, I don't think its quite worth it yet. As for deployment, well..that depends too. You can go as little as a P133Mhz (if you could find one) with linux, running a 100% java app server (like orion)..although it will probably be pretty slow. Because Orion is 100% Java, you can run it on any JDK 1.2+ platform, probably with little problems on all of them. I think the best deal, being that Orion is clusterable, is to use cheap Athlon or Intel based servers. You can spend $10K on a dual 900Mhz Dell server, or you can build a nice 1.1Ghz Athlon farm (say 3 servers per island, 2 islands) for as little as $1200 each. Since they are servers, opt for 4MB or 8MB video card, Win2K OS, JDK 1.3, and Orion. That is all we have on our server. We did put Diskkeeper, and have Terminal Services installed (with win2K Server), which allows us full administration of the server from anywhere. Figure $700 or so for Win2K, $1200 for the Athlon server (although I would wait a few more months to use the Athlon SMP servers coming out soon..where you can put dual athlons and they are more inline with Intel servers), $1500 for Orion, and a few hundred for other software (give or take). Each deployable server would cost under $5000 and you would have pretty darn good performance. Ofcourse, you can go with a Dell server and WebLogic..that would run you about $250K for the same setup that will cost you $30K with Orion (being that WebLogic is only 10x more expensive). I would also say it depends on your application. If that new Mac 8" cube had a dual processor in it, I would choose to run that! At $1700 for a computer that does 3GFLOPS of calculations, it beats the Intel and Athlon hands down in calculations..which is good for intensive math use. Thus, if you were building say an imaging farm that had to turn html into faxes (pdf, rtf, etc), I would opt for faster math capable cpus. Ofcourse..if I had my choice, I would really choose the Alpha cpu..that is what the Athlon is based on too. But, SUN offers a pretty good setup too, for a lot more money (usually). Honestly, if you want a setup that can probably handle several 1000 users at one time I would set up an Orion farm using Athlon or Intel 1Ghz+ servers, do two islands, each with 3 servers for fail-over and load-balancing (so you can handle more people). Do the same type of setup for the EJB servers..perhaps using dual cpu servers. Being that Orion costs nothing extra for dual/quad cpus, its ok to go that route. You can even buy a dual board with only 1 cpu and add a second cpu later (but don't wait more than 1 year..you wont be able to get that cpu if you wait that long..it will be obsolete). Hope that provides some insight. I would be very gratefull if anyone with experience tell me what it's the appropiate hardware to develope ejbs, servlets and jsps, and what it's the appropiate in order to run an app with a great load of concurrent users. I wanna know your opinion about what to choose Unix(solaris,HP,..) or Win (intel) for both development and real app. TIA. - David Sierra Fern ndez -- -- Sierr@ --
RE: HARDWARE FOR J2EE apps
-snip As for deployment, well..that depends too. You can go as little as a P133Mhz (if you could find one) with linux, running a 100% java app server (like orion)..although it will probably be pretty slow. Because Orion is 100% Java, you can run it on any JDK 1.2+ platform, probably with little problems on all of them. I think the best deal, being that Orion is clusterable, is to use cheap Athlon or Intel based servers. You can spend $10K on a dual 900Mhz Dell server, or you can build a nice 1.1Ghz Athlon farm (say 3 servers per island, 2 islands) for as little as $1200 each. Since they are -snip sounds very nice but what about the database? how do you cluster that without spending an arm and a leg? our experience is, that it's not that hard to set up clustered web services with static pages and servlets but the really expensive part is, when you want that high availability for your database. it doesn't buy you much if you have highly available ejbs when the database server goes down. many people use clustered apache/jserv on linux and cheap pc-hardware for high volume transactional websites but have a large enterprise sun running oracle in the back. anyone out there running a configuration with orion that includes a database with failover that doesn't blow up the budget too much (compared to other components)? robert (-) 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: HARDWARE FOR J2EE apps
Hi, sounds very nice but what about the database? how do you cluster that without spending an arm and a leg? our experience is, that it's not that hard to set up clustered web services with static pages and servlets but the really expensive part is, when you want that high availability for your database. it doesn't buy you much if you have highly available ejbs when the database server goes down. many people use clustered apache/jserv on linux and cheap pc-hardware for high volume transactional websites but have a large enterprise sun running oracle in the back. anyone out there running a configuration with orion that includes a database with failover that doesn't blow up the budget too much (compared to other components)? Well, to start off with there is mySQL and the one I like the most is Interbase 6..a free powerful RDBMS. However, as far as clustering them..I don't quite know the best way. I would think a load-balancer or a switch or something, would be required. Nobody ever said it was cheap! ;) I used to think $25,000 could easily set up a website from front to back, software, hardware, etc..but not even close these days. If you are just starting out, I would use Orion for front-end and ejb-logic tiers in a clustered environment (for developing/testing), with a single server running mySQL or Interbase for the database. Once you get some funding and move beyond the concept phase, you should put a sizeable chunk to invest in co-locating your site and doing the full load-balancing setup. I would estimate a cheap setup with 2 front-end web/servlet servers failed over, 2 ejb servers, and a database cluster will still run around $100,000, to co-lo it..which is probably the best thing to do to make sure its up 24/7.
RE: HARDWARE FOR J2EE apps
Hi! On Wed, 11 Oct 2000, Robert Krueger wrote: [description of budget-friendly Orion setup - snip] sounds very nice but what about the database? how do you cluster that without spending an arm and a leg? our experience is, that it's not that hard to set up clustered web services with static pages and servlets but the really expensive part is, when you want that high availability for your database. it doesn't buy you much if you have highly available ejbs when the database server goes down. many people use clustered apache/jserv on linux and cheap pc-hardware for high volume transactional websites but have a large enterprise sun running oracle in the back. anyone out there running a configuration with orion that includes a database with failover that doesn't blow up the budget too much (compared to other components)? Ah. Deja Vu. :-) I'm involved with a startup company here in Sweden, and considering Orion as app server we are also contemplating what non-arm-and-a-leg-spending ways there are to enable a database for failover and load-balancing functionality. We are looking at either PostgreSQL, InterBase, SAP-DB or MySQL (yeah, I know) as our database. We have not seen any currently freely available solutions for failover for either of those (anybody?). So, we are thinking about implementing something by ourselves. Nothing definite so far, but: - The synchronizing of data will be done on the application-level, not by the database servers themselves. See below. - We'll avoid numeric sequences for record keys to make this easier. We will implement some unique key-generation scheme based on whatever is needed to make keys unique but still not rely on strict monotone numeric sequences or similar ( md5(table_name+timestamp()), perhaps? ). - We'll code a DB-abstraction layer that takes care of executing all update queries against all configured database servers and all read queries against one of them known to be alive and lightly loaded (or not recently accessed, or some other scheme). - I guess that if we need database-specific stuff such as stored procedures or similar we need to use the same database software for all failover machines. - If we stay away from database-specifics we could possibly allow failover between different database products. Would be cool. Using straight, standard SQL, could make this feasible. These are very premature thoughts, we are getting closer to the planning and design stage, but we haven't actually started yet. Any thoughts? Ridiculously naive? Or possible to pull off? robert /David Reach me by - Email: [EMAIL PROTECTED], WWW: http://www.dtek.chalmers.se/~d0dak/ - --/David---
RE: HARDWARE FOR J2EE apps
Why would you use mySQL over Postgresl? They're both free, but Postgresql has a JDBC driver that's XA-compliant. Also, mySQL is known to blow away your whole database if it has a bad crash, whereas Postgresql is better at persisting data through a bad crash. How does Interbase 6 compare to Postgresql? Is it free? Scott Stirling West Newton, MA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Wednesday, October 11, 2000 4:01 PM To: Orion-Interest Subject: RE: HARDWARE FOR J2EE apps Hi, sounds very nice but what about the database? how do you cluster that without spending an arm and a leg? our experience is, that it's not that hard to set up clustered web services with static pages and servlets but the really expensive part is, when you want that high availability for your database. it doesn't buy you much if you have highly available ejbs when the database server goes down. many people use clustered apache/jserv on linux and cheap pc-hardware for high volume transactional websites but have a large enterprise sun running oracle in the back. anyone out there running a configuration with orion that includes a database with failover that doesn't blow up the budget too much (compared to other components)? Well, to start off with there is mySQL and the one I like the most is Interbase 6..a free powerful RDBMS. However, as far as clustering them..I don't quite know the best way. I would think a load-balancer or a switch or something, would be required. Nobody ever said it was cheap! ;) I used to think $25,000 could easily set up a website from front to back, software, hardware, etc..but not even close these days. If you are just starting out, I would use Orion for front-end and ejb-logic tiers in a clustered environment (for developing/testing), with a single server running mySQL or Interbase for the database. Once you get some funding and move beyond the concept phase, you should put a sizeable chunk to invest in co-locating your site and doing the full load-balancing setup. I would estimate a cheap setup with 2 front-end web/servlet servers failed over, 2 ejb servers, and a database cluster will still run around $100,000, to co-lo it..which is probably the best thing to do to make sure its up 24/7.
RE: HARDWARE FOR J2EE apps
How much time do you have? I say that becuase you may burn a lot of time trying to solve those database issues that are solved in some of the other commercial products. For replication you could use snapshots wither by doing exports/imports or data copying on a periodic basis so that you could at least recover fairly quickly I have not used DB2 but people have mentioned that it is fairly inexpensive when compared to Oracle. I would have thought that the SAP product would have had failover and perhaps even Postgress??? Cory At 11:37 PM 10/11/00 +0200, David Kinnvall wrote: Hi! On Wed, 11 Oct 2000, Robert Krueger wrote: [description of budget-friendly Orion setup - snip] sounds very nice but what about the database? how do you cluster that without spending an arm and a leg? our experience is, that it's not that hard to set up clustered web services with static pages and servlets but the really expensive part is, when you want that high availability for your database. it doesn't buy you much if you have highly available ejbs when the database server goes down. many people use clustered apache/jserv on linux and cheap pc-hardware for high volume transactional websites but have a large enterprise sun running oracle in the back. anyone out there running a configuration with orion that includes a database with failover that doesn't blow up the budget too much (compared to other components)? Ah. Deja Vu. :-) I'm involved with a startup company here in Sweden, and considering Orion as app server we are also contemplating what non-arm-and-a-leg-spending ways there are to enable a database for failover and load-balancing functionality. We are looking at either PostgreSQL, InterBase, SAP-DB or MySQL (yeah, I know) as our database. We have not seen any currently freely available solutions for failover for either of those (anybody?). So, we are thinking about implementing something by ourselves. Nothing definite so far, but: - The synchronizing of data will be done on the application-level, not by the database servers themselves. See below. - We'll avoid numeric sequences for record keys to make this easier. We will implement some unique key-generation scheme based on whatever is needed to make keys unique but still not rely on strict monotone numeric sequences or similar ( md5(table_name+timestamp()), perhaps? ). - We'll code a DB-abstraction layer that takes care of executing all update queries against all configured database servers and all read queries against one of them known to be alive and lightly loaded (or not recently accessed, or some other scheme). - I guess that if we need database-specific stuff such as stored procedures or similar we need to use the same database software for all failover machines. - If we stay away from database-specifics we could possibly allow failover between different database products. Would be cool. Using straight, standard SQL, could make this feasible. These are very premature thoughts, we are getting closer to the planning and design stage, but we haven't actually started yet. Any thoughts? Ridiculously naive? Or possible to pull off? robert /David Reach me by - Email: [EMAIL PROTECTED], WWW: http://www.dtek.chalmers.se/~d0dak/ - --/David---
