O/R Tool ObJectRelationalBridge 0.9 Released w/JDO, JCA Support


News: O/R Tool ObJectRelationalBridge 0.9 Released w/JDO, JCA Support

  1. There is a new version (0.9) of the opensource Object/Relational mapping tool ObJectRelationalBridge (OJB) available. The new version includes a JDO prototype implementation and sample app and full support for JTA/JCA, allowing it to be transparently pluggable into J2EE 1.3 servers. OJB will be joining Apache Jakarta before their 1.0 release.

    Check out http://objectbridge.sourceforge.net.

    More info
    ObJectRelationalBridge -- Bridging Java Objects and Relational Databases

    ObJectRelationalBridge (OJB) is an Object/Relational mapping tool that
    provides transparent persistence for Java Objects against relational databases.
    OJB supports multiple APIs:
    - A full featured ODMG 3.0 compliant API.
    - A JDO compliant API
    - A low-level PersistenceBroker API which serves as the OJB persistence kernel.

    OJB can be used in single VM mode or in a distributed, loadbalanced Client/Server mode.
    OJB uses an XML based dynamic Object/Relational Mapping that can be manipulated at
    runtime through a simple Meta-Object-Protocol (MOP).
    OJB provides several advanced O/R features like M:N associations, a pluggable ObjectCache,
    lazy materialization through virtual proxies and
    a distributed lock-management with configurable Transaction-Isolation Levels.

    Changes in Release 0.9

    new features:
    - Servlet Implementation of PersistenceBrokerServer, allows
      to easily deploy the OJB Server as a Http-Servlet
    - JDO prototype and sample application.
    - complete redesign of the repository grammar.
    - performance test-suite for the ODMG implementation
    - Full JTA and JCA integration!
    - PersistenceBroker interface now extends the
      org.odbms.ObjectContainer interface
      to provide a better integration for the S.O.D.A query API.

    bug fixes:
    - tons of bug fixes

    - performance enhancements
    - redesign of SqlGenerator
    - redesign of the build process, now using Torque and Maven
    - redesign of Repository parser
    - ConversionStrategies have been moved from the class-level to the field-level.

    With this release we are feature complete for the 1.0 release!

    For 1.0 you should not expect more features to be added.
    In OJB 1.0 we will have more bug fixes, better documentation and we will add the prefix "org.apache" to all ojb packages to reflect our new home at Jakarta.

    More information is available at http://objectbridge.sourceforge.net

    Threaded Messages (19)

  2. Has anyone here used this who would be willing to share their experiences? Sounds interesting, but I don't know if it is worth my time to figure out.

  3. I'm using it with the Struts book that I'm currently writing. Although the application that I'm writing is simple and obviously will never go into production, I've used the the OJRB framework quite a bit to get up to speed on it and it's very nice and complete.

    If you have some experience with other frameworks, you'll be pleasently surprised about how much is there and functioning. I personally would say it's worth a look.

  4. How is the performance? Is it ready to be deployed in production environment?
  5. re OJB performance[ Go to top ]

    OJB ships with a performance testsuite comparing its performance against native JDBC.

    So you can determine the exact overhead for a given platform!
    see: http://objectbridge.sourceforge.net/performance.html for details.

    The OJB obverhead depends quite a lot on the RDBMS backend and on the JDBC driver you are using. But for most application scenarios and for properly implemented JDBC-drivers the overhead is typically < 15%.

    OJB has been used in production environments since more than a year now.
  6. I'm just playing around with release 0.9 because we are looking for an O/R tool for our next project. Our main production database system is IBM DB2 7.2. Database systems MS SQL server, Oracle, MySQL and postgreSQL should be supported as well. With IBM DB2 7.2 i run the performance test. Unfortunately the results are disappointing:
    - Using OJB the overhead is about 60%.
    - Using ODMG the overhead is about 700%.

    Is there a problem with IBM DB2?

    If someone is interested in the complete output of the tests i'd likely send an email with the results.

    best regards, thomas
  7. The progress that OJB has made over the last 2-3 months is phenomenal.

    Thomas's architecture is rock-solid and easy to become familiar with, fix bugs on, and extend.

    With the latest 0.9 release I think OJB is ready for most people to use in a production environment.

    Performance is great with PersistenceBroker, and getting better with ODMG api (granted ODMG is a heavier api).

    The 1.0 release will be INCREDIBLE.

  8. We're using it quite sucessfully. A really great tool. It is easy to learn, well built, and robust.

    Our performance test have come out great, and we're planning to use it in the next release of a set of datamining tools that we're developing. I agree with Matthew that the performance on the broker is great, and pretty good on ODMG. I am very much looking forward to the JDO implementation.

    We've tested it so far on Postgresql, Oracle 8i, Sybase ASE12.5, and SQL Server 2000 without any problems. And we've tested with various app servers with no problem.

    The documentation is lacking, and currently the documentation and tutorials are at lease two versions old, but most things work the same way still.


  9. "The documentation is lacking, and currently the documentation and tutorials are at lease two versions old, but most things work the same way still. "

    What do you mean by this ? Are there any big differences between what the documentation states and what is actually implemented in the 0.9 version ? For exemple, is the XML mapping described in the tutorials still valid ?

  10. From my recent experience no, the XML mapping in the HTML docs is out of date. The actual tutorials, code and XML schema mapping are valid and work. For instance, the new XML mapping mostly specifies parameters as XML element attributes, and not as sub-elements.

    Just my $.02
  11. the performance question is obviously a good one, and one where a good deal of scepticism towards quick answers is in order. Comparing OJB performance with JDBC on the API level does not help much. The real question is, with complex operations like traversing an object tree, or gathering report data spanning several entities, how efficiently can this be done / is this done with either approach. I have found in many scenarios, hand-craftet SQL (via JDBC) will outperform generic data framework code by several magnitudes, and I dont see how this will change.

    One notorious area is loading relationships. Many frameworks take the approach of first loading all primary keys, and then loading the object data proper once it is accessed. This can make for horrific performance. So beware.

  12. OJB provides several advanced feature like dynamic proxies for implementing lazy load scenarios.
    Using proxies can do a very good job to improve the performance with large object nets.

    OJB also provide ReportQueries and free form SQL Statements.
    It also provides mechanism to elegantly obtain JDBC connections do perform performance critical DB access manually.

    Of course an generic framework will *never* reach the performance of handoptimized SQL.
    Even commercial O/R layers aren't much better in this respect...
  13. Hi

    I am new to OJB. But i am really excited about it. I want to use it with ejb (session bean) I would like to know how i can use it with ejb. I would be happy if somebody can tell me few things.
    1) where should i place OJB configuration files in ejb jar file
    2)where and how should i create PersistenceBroker object. Can it be lookedup using jndi. if yes how shoud i register it using jndi.
    3) If i am using container managed transaction then will OJB run it that transaction scope.
  14. I've had no performance problem with OJB. Like Thomas said, the SQL could be tuned, but depends on what you need.

    If you need absolutely the best performance on every database call?

    However, OJB has some pretty good facilities for lazy loading/lazy instantiation of objects that can help a lot with performance.

    If you need database neutrality like I do, then you'd have to write a factory for all of the different databases that you support. Instead OJB and company have done all this for you, with good transactional, caching, and performance facilities.

    Saves a huge amount of development, makes our apps more stable, more extensible, easier to maintain.

    On top of which, performance really is better than a lot of EJB systems, although that's kind of a specious comment, since OJB doesn't handle all the services that EJB offers. A little bit of apples and oranges.

    Even if performance was say, 10% - 15% worse, I'd still say the values I mentioned above outweigh it for me. App server licenses are cheap.

  15. ad 1. see: http://objectbridge.sf.net/deployment.html
    ad 2. PersistenceBrokers are not serializable. You usally use the PersistenceBrokerFactory to obtain and relase broker instances (the factory provides a pooling mechanism to effectively share brokers accross client requests)
    ad3. Yes! OJB provides full JTA integration on PersistenceBroker and ODMG level.
    There is also a JCA adaptor to smoothly integrate into JBOSS & co.
  16. What would be the advantages of using this tool over implementing O/R using plain Entity-Beans in terms of:

    - Coding ( quantity and ease )
    - Deploying
    - Perormence

    What is the most common data-access scenario which this tool is best implementing with?

  17. What would be the advantages of using this tool over

    > implementing O/R using plain Entity-Beans in terms of:
    > - Coding ( quantity and ease )

    with OJB you can persist just any class. There is no need to implement special interfaces, derive from a special baseclass, care about finder methods etc.

    you won't need any EJB infrastructure to model, implement, test and deploy you persistent classes.

    All advantages of the JDO and ODMG programming model apply to OJB!

    > - Deploying
    No special deployment is needed for persistent classes. OJB relies on metadata describing the persistent classes. This information resides in a repository.xml file (or a repository.jdo file in our JDO implementation). This file can be easiliy deployed in a .war or .ear archive.

    > - Perormence
    It's difficult to make any general statements here. Depends mainly on how efficient your appserver handle entity beans.
    (My tests on WebSphere showed that OJB is 4-5 times faster than bean-managed entity beans.)

    Of course you can use OJB to implement bean managed entity beans if you like.
    There is example for this shipping in our regression testsuite

    > What is the most common data-access scenario which this
    > tool is best implementing with?

    What do you mean by data-access scenario?

  18. What i ment asking by 'what common data-access scenario...'
    question, is for which application model would you say this tool is most suitable (does better job than others):

    - Large row-set, read only data...
    - Mostly read data, sometimes update...
    - Mostly updated, seldomly read..

    Can you guys share an exmaple of an implementation made with jdcb/EBs then made better by this tool?

    Also, how is sharing data across cluster node handled:

    - Is there a mode for replicating all updated data in real-time?
    - Setting 'dirty' flags?

    Thanks for the information,
  19. OJB ships with a performance testsuite to allow performance benchmarks against your specific JDBC driver and RDBMS.
    (see: http://objectbridge.sourceforge.net/performance.html)

    This testsuite compares perfoemance of the OJB persistence-kernel against native JDBC performance.
    it benchmarks:
    - insert objects
    - update objects
    - select objects by primary key
    - select again to check cache performance gain
    - fetching object from a cursor
    - deleting objects

    Our test show that OJB is very good at querying and fetching.
    The overall performance loss as compared with native JDBC depends mostly on Jdbc-Driver and RDBMS, but is typically only 10 - 15 %

    I don't have any figures comparing OJB to other O/R tools.

    Our regression testbed inlcude all kind of example code:
    - PersistenceBroker client apps
    - ODMG client apps
    - JDO client apps
    - Servlet apps
    - EJB SessionBeans
    - BeanManaged Entity Beans
    - mixing OJB with native JDBC programming
    etc., etc.

    There is a document covering OJB clusters:
    (see: http://objectbridge.sourceforge.net/system/clientserver.html)

    OJB provides synchronous cache synchronisation between all clustered servers.
    It also provides a distributed lock-engine to allow full-fledged object-level pessimistic transaction isolation.
    (see: http://objectbridge.sourceforge.net/system/lockmanager.html)
    We have implemented four isolation levels: "read-uncommitted", "read-committed", "repeatable-read", "serializable".

    (Of course optimistic locking is also provided, but this needs no communication accross the cluster)

  20. We ve been using Castor for quite a while, and I'd like to know how OJB compares to Castor in terms of flexibility, features, and performances.

    TIA, johann