THOUGHT Inc. has announced the release of Version 5 Service Release 1 of CocoBase PURE POJO with EJB 3 JPA specification integration and support, the new Java standard API for Object to Relational Mapping. The Java Persistence API (JPA) is the formal standard for programming data persistence on the Java EE and Java SE platforms. With this release of version 5.0 Service Release 1, corporate applications built with the JPA can easily utilize the Dynamic O/R Mapping architecture of CocoBase to manage the persistence of data for their companies. CocoBase offers a number of key advantages for developers programming with the EJB 3.0 JPA that are not available with JPA implementations from other key ORM tools: 1) Includes the CocoBase GUI designed specifically for ease of use and high productivity. 2) Provides another commercial persistence technology and platform in which JPA is integral. This allows the developer to make use of the basic features supported in the JPA as well as the extensive additional persistence functionality and mapping and runtime features of CocoBase (as in other commercial implementations.) The patented CocoBase Dynamic O/R Mapping architecture was designed from the beginning to easily manage the full range of persistence requirements from simple to complex. 3) Provides a high performance and scalable persistence solution. The CocoBase Persistence Manager is designed such that applications run up to 2 to 3 times faster than the same calls hand-coded with just a JDBC driver. This performance along with the linear scalability characteristics of CocoBase ensures that applications easily meet usability expectations and cut the costs or need of additional software or hardware. 4) Provides the only major commercial (non open-source) ORM tool implementation of the EJB 3.0 JPA. This allows corporate applications to take advantage of a patented and source-code protected code base. The CocoBase JPA solution is an integral part of the toolset that was designed tightly and cohesively by the same engineering team that built the tool from the beginning. The result takes full advantage of the decade old mature and stable persistence technology that is a key requirement for use in mission critical corporate applications. CocoBase is a commercial product; quotes are made on a per-customer bases. There's a free download available for evaluation. [Editor's note: the claims made in this news post haven't been substantiated (or proved false!) by TSS. Note the comparison above against hand-coded JDBC depends highly on the nature of access and how JDBC is used for an example of such claims. We're more than interested in a benchmark showing the results of CocoBase against other implementations, tuned and untuned.] Message was edited by: joeo@enigmastation.com

Sorry but this argument can't be true. Everything a mapping tool can do automatically can be coded by hand (reusing of prepared statements, batch update, etc.). And hand coding can be even more cusomized than a mapping tool can ever do "understand" the problem. i searched the thoughtinc website and could not find any source of this "performance test". once again: i think this is a marketting gag! btw: how does cocobase compare to other (free) mapping tools?

Sorry but this argument can't be true. Everything a mapping tool can do automatically can be coded by hand (reusing of prepared statements, batch update, etc.). And hand coding can be even more cusomized than a mapping tool can ever do "understand" the problem.

i searched the thoughtinc website and could not find any source of this "performance test". once again: i think this is a marketting gag!

I agree that in a direct comparism of a hand coded and a generated JDBC statement the performance of the first one always will be better. But an advantage of O/R mapping tools is the transparent integration of caching mechanisms which allows such kind of results. This especially applies for queries: after generating and executing the statement the O/R mapper at first only decodes the identity (the primary keys) of a fetched row and tries to fetch the corresponding object from the cache. In case it exists there this approach is normally much less time consuming than decoding the entire row or set of rows which represent this object. I imagine that adding such logic to a hand coded JBDC solution also adds quite a bit of complexity to the application which may not be desired. Therefore saying "2 - 3 times faster than hand-coded with just a JDBC driver" may be true under the given circumstances. I think in general it´s ok to use these results for marketing but there should be something like an explaining footnote.

Ward explained it a few years ago, and it was just one test that he did that showed a quirk in the Hotspot compiler. As a result, there are no general reproducible tests that will show this claim to be true. Peace, Cameron Purdy Tangosol Coherence: Clustered Cache for Java

I disagree. Caching has significant implications on the application behavior, and must always be taken into account in non-trivial applications. Therefore comparing a non-caching approach to a caching one is apples to oranges. The correct claim would have to be "2 - 3 times faster than hand-coded with just a JDBC driver AND NO CACHING". Its all marketing.

Nope, here is Ward's explanation:

> > If you need O/R mapping features not in Hibernate, just get CocoBase. It's the only O/R tool that outperforms RAW JDBC without caching enabled.

Do you use something "faster" than JDBC to impement this product ? Or do you think we are too stupid to understand nonsences you have posted ?

We use JDBC under the hood, but our architecture makes it possible for hotspot to better optimize our code than raw JDBC does. We ship the test harness and testcases as source code with our product. I doubt you're too stupid to understand the concepts, but it can take years to produce a reliable implementation that achieves this kind of performance behaviors... Just my $.02 Ward Mullins CTO THOUGHT Inc. http://www.thoughtinc.com

From http://www.theserverside.com/news/thread.tss?thread_id=20376#89393 Peace, Cameron Purdy Tangosol Coherence: Clustered Cache for Java

We use JDBC under the hood, but our architecture makes it possible for hotspot to better optimize our code than raw JDBC does. We ship the test harness and testcases as source code with our product. I doubt you're too stupid to understand the concepts, but it can take years to produce a reliable implementation that achieves this kind of performance behaviors...

Can't understand this, it's contradictory to me. If Cocobase use JDBC under the hood (as all Java O/R mapping tools do) how the code using Cocobase can be faster then the hypothetic plain JDBC code that Cocobase will actually call. Is this related to method in-lining so that HotSpot in-lines methods differently so that code using Cocobase is actually faster? If this could be so, than it is the problem with HotSpot and not the feature of Cocobase.

Nope, here is Ward's explanation:

> > If you need O/R mapping features not in Hibernate, just get CocoBase. It's the only O/R tool that outperforms RAW JDBC without caching enabled.
>
> Do you use something "faster" than JDBC to impement this product ?
> Or do you think we are too stupid to understand nonsences you have posted ?

We use JDBC under the hood, but our architecture makes it possible for hotspot to better optimize our code than raw JDBC does. We ship the test harness and testcases as source code with our product. I doubt you're too stupid to understand the concepts, but it can take years to produce a reliable implementation that achieves this kind of performance behaviors...

Just my $.02

Ward Mullins
CTO
THOUGHT Inc.
http://www.thoughtinc.com

From http://www.theserverside.com/news/thread.tss?thread_id=20376#89393

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Cache for Java

I'm also skeptical that HotSpot optimizations get such a large overall performance increase than RAW JDBC. Maybe it takes 2-3 times less CPU time on the client, but the roundtrips to the database are probably at least an order of magnitutde in time over JDBC execution. If you get my drift. Bill

There's also the JDBC driver in the way, where a lot of CPU time is wasted too, so unless they do some very obscure black magic, that's a very doubtful figure indeed.

And if they improved the overall JDBC performance, why these improvements have not been directly implemented in JDBC? Are they related to specific drivers optimized by Cocobase? I think everybody here do agree that this argument is non-sense (except probably Cocobase marketing team). Cyril

4) Provides the only major commercial (non open-source) ORM tool implementation of the EJB 3.0 JPA. This allows corporate applications to take advantage of a patented and source-code protected code base.

At times where every major companies have accepted the Open Source world (Linux, Firefox, Apache projects), a world supported by computer industry itself (IBM, BEA, Sun...), how can this be truly a serious argument? Closed source is a disadvantage, and I'm very surprised some marketing teams are still trying to generate FUD from it.

The CocoBase JPA solution is an integral part of the toolset that was designed tightly and cohesively by the same engineering team that built the tool from the beginning. The result takes full advantage of the decade old mature and stable persistence technology that is a key requirement for use in mission critical corporate applications.

Typical marketing and empty argument. Come on, guys, we are on a technical web site! What's the problem if newcomers join the project with new ideas? Are there any proof that your technology created 10 years ago is more "mature and stable" than any other? The GUI is a good thing (from my point of view), and support for JPA is also a good thing (congratulation!). I like having choice between persistence implementations, but the real quality of a framework depends on the code and design, not on the communication around it. Cyril

Provides the only major commercial (non open-source) ORM tool implementation of the EJB 3.0 JPA.

1. Firstly since there are several good open source implementations around all backed by commercial support, this is a complete misnomer. Secondly BEA Kodo JPA is commercial and not open source (whilst the underlying Open JPA is open source). Therefore the "only major commercial" line is also misleading. But then marketing will come out with all sorts of crap when money is mentioned. 2. Does this release of Cocobase pass the JPA TCK ? i.e is it correctly implementing the full JPA1 spec ? (not that this says much)

In other related news, CocoBase outperforms JDBC.

... This allows corporate applications to take advantage of a patented and source-code protected code base.

I stopped reading after this bit. "source-code protected code base", what value does this add to its customers?

... means that software patent protected runs 2 to 3 times faster than "unprotected" source code ;-) has someone did performance tests? would be very interesting: cocobase vs. hibernate or any other opensource o/r mapping tool.

has someone did performance tests? would be very interesting: cocobase vs. hibernate or any other opensource o/r mapping tool.

No. It's commercial so you wouldn't be allowed to post the results to see how amazing their times are on a valid benchmark. *That* is the "advantage" of "source-code protected code base" :-)