|
C-JDBC
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
|
Users and Success Stories
Tell the community how you use C-JDBC
We need your feedback
Let us knnow your usage of C-JDBC even if it is not in production.
You can send the information by email to c-jdbc@objectweb.org.
Relevant information could include:
- Company: name, logo, link, contact point
- Application type: eCommerce, banking, ..., link to website
- Current status: evaluation, migrating, production, ...
- Additional information about your setup: number of databases, db
size, number of transactions, application server, backend vendor
(MySQL, PostgreSQL, ...), OS, JDK, ...
Your contribution will be very valuable to the whole community.
Thanks in advance to all contributors,
The C-JDBC team
Use cases
Marathon Computer Systems
C-JDBC allowed us to easily solve the scalable and fault
tolerant database requirement without resorting to expensive
commercial products.
Description:
We have just begun development of an application that will be served
over the web "ASP" style. I'm not certain if I'm at liberty to
divulge the nature of the application, but in the end we hope to
serve hundreds of customers from our web interface. The application
will have intense scalability requirements (clustering, load
balancing, automatic failover, etc) and will also expose a web
services API. Our current architecture is as follows (from the lowest
levels to the highest):
-
PostgreSQL: for database backends.
-
C-JDBC: to handle clustering multiple PostgreSQL
instances on the backend. We will be utilizing load balancing and
failover.
-
Hibernate: While we will be using the Data Access Object
pattern, our actual data access objects will be implemented with
Hibernate, providing a rich object relational mapping.
-
JBoss: Because of our scalability needs, we will be
deploying our business logic behind EJB facades. JBoss will then
give us the ability to "cluster" the business logic. JBoss takes
care of gory details like transmitting a principal's security
information with remote method invocations and so on, which is
necessary when scaling an application across many servers. It also
provides a path for exposing the business logic (services) as web
services.
-
Spring: This is for the middle layer. It may be that
down the road another type of container comes out providing
advantages over J2EE, so we don't want to be tied to J2EE (there
are some things we don't like about it) - - we implement all our
business logic in "seemingly" POJOs that use interfaces for
accessing external resources (whether that be a DAO or another
service interface, etc). We use Spring to wire together and
configure our business logic layer with DAOs (Hibernate) and other
services via the interfaces. We also use Spring to "wire" and
configure the client (web) side and to create transparent proxies.
As far as the client is concerned, it is simply accessing any
normal interface. Spring takes care of implementing our service
interface with a proxy that proxies method calls to an appropriate
EJB. If we should decide to move away from J2EE in the future, it
will only require changes to our Spring configuration, not to our
codebase.
-
JSF: We are still exploring our client side. We are
looking at using JSF for the web interface, though we are also
exploring a rich client implementation.
Contact: Andy Depue (andy at marathon-man dot
com)
Dimago
ASP solution in the tourism sector, using c-jdbc for failover
and load balancing
Description:
C-JDBC is used to build a database cluster with inexpensive
hardware and open source databases (postgreSQL) to achieve load
balancing and failover at low cost. (www.dimago.ch, directory.dimago.ch)
Configuration : raidb1 configuration with budget servers in two
different datacenters Environment : Linux, PostgreSQL,C-JDBC,
Tomcat, Apache
Contact: Marc Wick (marc.wick at dimago dot ch)
C-JDBC on the web
Threads about C-JDBC
Sites referencing C-JDBC
日本�?�CーJDBC
Awards
| |