Slashdot Mirror

← Back to Stories (view on slashdot.org)

C-JDBC 1.0 Released

Posted by michael on from the ready-to-rumble dept.

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."

14 comments

  1. cloudscape by raffe · · Score: 1

    Will it work with the asf cloudescape db?

  2. 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!

  3. 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.

    1. Re:Nonsense... this is an awesome project by StupidEngineer · · Score: 1

      Oops, sorry, yeah. :) My bad, grammar bad. :) Missed a comma.

  4. 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.

  5. Memcached by captainclever · · Score: 2, Interesting

    This looks like a very cool project.

    For all those people reading this thread looking for a cheap way to resolve DB load problems for websites etc, check out Memcached:

    http://www.danga.com/memcached/

    After adding a memcache layer to your site you might find 1 lowly database server is more than enough ;)

    --
    Last.fm - join the social music revolution
  6. ha-jdbc by StupidEngineer · · Score: 1

    BTW, has anyone checked out the HA-JDBC project? http://ha-jdbc.sourceforge.net/

    It's not as feature rich as c-jdbc, but it might be another alternative for us that avoid the expensive clustering systems. /still feels stupid about incorrectly submitting the news item.

  7. How about transactions? by TheSunborn · · Score: 1

    I looks very intelesting, but I searched the documentation and could not find any mention of transactions. How do they handle that?

    I mean how do they handle locking with things such as SELECT FOR UPDATE?
    I mean if to clients different SELECT FOR UPDATE fon the same row, could you not have a situation where one client have the lock on db1 and an other client have the lock on db2 for the same row?.

    And how do they handle transaction order. I mean if to transactions a and b are comitted at the same time, could you not risk, that one database first commit a and then b, while the other commit b first and then a, leading to inconsistent databases.

    The only way I can se to handle this, is to have the software be total single threaded with only one thread sending read/write requests to the databases and then block until all databases had acknowledget them. But that would be slow.

    1. 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.

    2. Re:How about transactions? by Anonymous Coward · · Score: 0

      Basically, they don't handle such things. This is for java weenies who use databases as simple persistence layers, not people who actionally understand relational data modeling.

    3. Re:How about transactions? by atallah · · Score: 1

      You obviously are trying to be flamebait, but in addition you are severely confused - J2EE Container Managed Transactions are extremely effective, going beyond simple database transactions and extending to application transactions, where several different types of entities can be rolled back (e.g. Message Queues) in addition to database transactions.

  8. Nice project by jfsather · · Score: 1

    It is nice to see a project like this. Kind of odd since I was just asked to look into how to do this. It would be helpful if you had to use Tomcat, but most of the paid for servers already have something like this (e.g. MultiPools in WebLogic).

    Of course it would be useless if you couldn't cluster the C-JDBC server as well--the reason you are using multiple DBs is to not have a single point of failure.

    Now what I have to figure out is syncing all the databases--that would be quite a few triggers that need to be created. Or is it easier than that? I'm not a DBA, so I really don't know.

    -J

    1. Re:Nice project by jfsather · · Score: 1

      Okay, I RTFDocs and figured out what it is doing. Selects are balanced and anything else is broadcast (including stored procs). Not a bad way to do it, but then you would need to be very aware of response times from each DB since on an update/insert it would seem that it would take as long as the slowest responding DB. No real way around that, I'm guessing. It is probably best with multiple instances of the same DB type rather than the mix-type they show in the docs, however. All of this, of course, assumes that the databases are your limiting factor and not the network or hardware. That and you get worst case performance from anything other than a select.

      That whole transaction comment in this tread bothers me a bit knowing how this is working--especially the commit/rollback part of it.

      Still an interesting project, though.

      -J