Forum OpenACS Q&A: Interbase has gone open source.

Collapse
1: Interbase has gone open source.
Posted by Connie Hentosh on 07/25/00 08:07 PM
Well it looks like interbase has finally done it. http://www.bor land.com/about/press/2000/ib6.html You can now get the source from www.interbase.com. So anyone know what the effort would be to port to interbase? I am just a beginer at SQL.
Collapse
2: Response to Interbase has gone open source. (response to 1)
Posted by Roberto Mello on 07/25/00 08:19 PM
Has the superserver gone open source too yet?  AFAIX it's only worth to port to the superserver.
Collapse
3: Response to Interbase has gone open source. (response to 1)
Posted by Blah Blah on 07/25/00 10:24 PM
Collapse
4: Response to Interbase has gone open source. (response to 1)
Posted by Don Baccus on 07/26/00 12:42 AM
Not kind of "blah blah" to use a fake name, e-mail address, and web URL.

I haven't checked the website, but the superserver was supposed to go Open Source.  Getting it ready is what supposedly prevented everything going Open Source six months ago.

InterBase supports stored procedures, but I don't know how easy it would be to port the PL/SQL routines to them.  Postgres' PL/pgSQL was designed to be a poor-man's PL/SQL and because of this porting such functions has been surprisingly simple.

InterBase has outer joins, but only the SQL92 syntax (the right thing to do, abstractly, but less help for the ACS).  So all outer joins need rewriting, but the task would be simpler than it is in Postgres.

There's no oracle-style "sequence", either, so key-generating and communicating code would need to change, that's kind of a pain.

Etc.  A port would be a major effort, on about the same level as Postgres.

The good news is that ACS 4.0 should centralize a lot of the SQL porting effort, so supporting both InterBase and PG could in theory be  more easily done with one code base.  We'll see when it comes out.

Collapse
5: Response to Interbase has gone open source. (response to 1)
Posted by Dave Bauer on 07/26/00 01:23 AM
The supreserver is available for Linux at least according to http://inprise-chil.www.conxion.com/ The "Classic server only support one process and one connection per machine, so you definitely need the SuperServer version.
Collapse
6: Response to Interbase has gone open source. (response to 1)
Posted by Janne Blomqvist on 08/11/00 12:14 PM
The above answer is wrong. The Classic server is a "classic" unix server, ie. for each connection it forks a backend to handle the request. This is similar to what postgres does. The Superserver is a threaded server, ie. only one process handling all requests. The threaded model is generally thought to be better (for example AOLserver uses it, compared to apache 1.x, a pre-forking server). I don't know if the postgres project plans to make postgres a threaded server. Anyway postgres uses shared memory and other stuff to make up for some of the problems forking servers. And with persistent database connections, the time to fork the backend doesn't matter so much anyway. The thing I want most of all in postgres is outer joins (I really hate to do those clunky unions and subselects...). Luckily they are supposed to be included in 7.1, scheduled for release in late October ackording to a message some days ago in pgsql-general.
Collapse
7: Response to Interbase has gone open source. (response to 1)
Posted by Don Baccus on 08/11/00 04:59 PM
Jamie's right...the major problem with IB Classic is that it doesn't use shared memory, you can have as many processes/connections as you want.

The big win will be from the fact that the threaded, "superserver" uses shared memory to share buffered blocks between threads, etc.

Postgres does use shared memory which is why it does so much better than InterBase classic under heavy load, even though it's not threaded. As noted the persistent database connections held by AOLserver (long live AOLserver!) means that the potentially painful overhead of forking new backends in reality isn't, for us here at OpenACS.

It will be interesting to see if InterBase can hold its speed advantage under light load now that it includes the locking overhead inherent with aggressive use of shared memory.

Unfortunately, outer joins are scheduled for 7.2, not 7.1.  For some reason the core developers don't understand why some of us think they're so crucial.  Feel free to rant and rave and scream at them.

Collapse
8: Response to Interbase has gone open source. (response to 1)
Posted by Ben Adida on 08/11/00 05:35 PM
One quick point: the threading model certainly hasn't been shown to be better in *every* situation. As Don mentioned, high-end systems like ACS/OpenACS use connection pools, with maybe up to 20 simultaneous, always-open connections. Threads aren't necessarily better in this scheme, especially given that there are many bad thread implementations out there (ahem... Linux).
Collapse
9: Response to Interbase has gone open source. (response to 1)
Posted by Janne Blomqvist on 09/05/00 11:54 AM
Hmm... As Ben notes above, threads can be done poorly too. IBPhoenix (the current name of the company which was supposed to take over the interbase stuff from inprise) has some interresting documents on their website. A KnowledgeBase Article by Ann Harrison herself describes that the interbase superserver (=the threaded server) has such a sucky thread implementation (threads can't execute in parallell) that it cannot take advantage of SMP, leading to only 5-20% better performance on a 2-way system. And performance degradation on NT because NT is so smart that it notices that one processor is idle, switches the database process to the idle processor, then notices that the first processor is idle and switches the database process back to it etc... :)