Slashdot Mirror


C-JDBC 1.0 Released

StupidEngineer writes "The C-JDBC is a middleware RAID system for databases written in Java. The 1.0 release is finally ready for download after years of the team's hard work. The system definitely has come a long way and is probably a very viable solution for those of us that can't afford large DB clustering solutions, yet still want good scalability and redundancy."

4 of 14 comments (clear)

  1. Fantastic! by Anonymous Coward · · Score: 2, Informative

    This is an excellent idea: write a JDBC driver that talks to other JDBC drivers to make your application think you have only one database server, all the while this funky meta-driver does load balancing and replication, thus automatically augmenting your application's database availability and performance. Cool!

  2. Nonsense... this is an awesome project by JavaRob · · Score: 3, Informative

    Um... this isn't a database engine (though there *are* database engines written in Java). And I think you're still thinking of Java applets, which is really not a strong point. I'll skip the rant in favor of providing some actual info on the project, though, since it looks really cool.

    Here's the homepage, with much better info that the download link above.

    Basically, they provide a standard JDBC interface that your application can use normally (no code modification needed at all!). The driver forwards the SQL requests to a central controller that balances them on a cluster of replicated databases (reads are load-balanced and writes are broadcasted).

    You can use it with any RDBMS providing a JDBC driver, i.e. almost all existing databases -- anything from Oracle and DB2 to MySql and PostgreSql to, yes, Cloudscape -- anything with a JDBC driver.

    Sweet, huh?

    It's also highly configurable and extensible (you can even mix *different* kinds of databases in your cluster!), with plug points for adding custom request schedulers, load balancers, connection managers, caching policies, etc.

    This could be a godsend for some of my projects. Database access seems to always be the bottleneck that's hardest to fix without complex and expensive solutions.

  3. Anything with a JDBC driver by JavaRob · · Score: 2, Informative

    More details in my post below, but yes -- basically any RDBMS with a JDBC driver is suddenly fair game for clustering. You can even have heterogeneous databases in your cluster!

    Cool stuff.

  4. Re:How about transactions? by JavaRob · · Score: 2, Informative

    The docs (try the user guide) do mention transactions, but I didn't see any detailed discussion of how they handle it....

    Honestly, you *might* have to wait until all databases were finished, when performing an update, insert or delete. Otherwise how could it possibly handle a rollback (which the docs do mention, so they're supported)?

    This isn't as bad as it sounds, though. It's not as if the databases were updated in sequence; they're all updating at once, so it won't take any longer than if you were using a single database, and not clustering at all. And you still have the huge benefit of huge, myriad-join selects running on the nodes independantly of each other... which is where this would really help my projects out. I don't do many intensive updates/deletes/inserts... it's the reports that do lots all the calculations using data from dozens of tables that start dragging things down.

    I'm no expert on how database clustering normally works.. so anyone feel free to jump in here.