Solarmetric has made two TORPEDO submissions at 16 and 21 hits. Their 16 hit submission ties the mark set by Versant earlier this week. This is in addition to the 22 hit submission Solarmetric made on 8/31. The Non-Verified submissions were made using Solarmetric Kodo JDO 3.2.

Here is a summary of the result notes from Solarmetric's submission:

Single server; Modified TORPEDO to take advantage of Kodo's automatic relationship management and JDOQL subquery support; Optimized configuration and JDO metadata.

To see all of the results: http://MiddlewareRESEARCH.com/TORPEDO/

The TORPEDO Launch Discussion.

This is good! My congratulations!
Looks like JDO implementations are in the lead over other persistence methods.

Too bad JDO was killed recently by decision to assimilate it into EJB3...
This will definitely turn off potential new comers to JDO since its future uncertain now...
I guess next step app. server vendors (and relational DB vendors) will take is to lobby Sun to deprecate JDO altogether in favor on "new EJB3 umbrella POJO" that will be delivered (if ever) in X years...which is really bad news for Java development community.
I'm amazed how some big vendors political games influence Java in a bad way...

This is good! My congratulations!

Thanks!

Too bad JDO was killed recently by decision to assimilate it into EJB3.

Just for the record: JDO2 is very much still alive -- we're actively working on the expert group to get the next draft out the door, and are pretty happy with where we've gotten to date.

Regarding the future, maybe I'm just a starry-eyed optimist, but I don't think that Sun's actions will kill JDO. Sure, there is quite a bit of overlap between JDO's scope and that of the JSR220 team, but I think that the situation is much better now than it was two weeks ago. Historically, the persistence expertise in the Java community has been split between the two different teams. I'm confident that establishing collaboration between these teams will cause both the JDO and JSR220 groups to benefit.

Only time and the Java community will tell which specification ends up becoming the dominant one. But, with sufficient collaboration between the teams, I think that the one thing we can count on is that the specs will drive each other to excel.

Further, I'd expect that implementations that support both specifications will provide pretty seamless compatibility between the different standards, so you'll be able to access those parts of each spec that you like and get hands-on experience with both at the same time, which will help the community figure out which API set works better in which environments.

-Patrick

--
Patrick Linskey
Kodo JDO
SolarMetric Inc.

I truly hope you are right and JDO will live as an active standard for POJO persistence.
Personally, I really like new additions in JDO2.0 (especially JDOQL and standard O/R mapping).
Thanks to Robin for his article (series) that goes over the JDO2 changes...

Thanks to Robin for his article (series) that goes over the JDO2 changes...

You've only seen Part I so far. Part II will be online soon, and Part III will blow you away!

Kind regards, Robin.

Robin,

I really appreciate you hard work on promoting JDO technology!

Looking forward for the next series...It is a really good resource.
Also, I liked your SDO/JDO comparison article.

Too bad, JDO was not chosen as an underlying persistence for EJBs. JDO has really matured.
I guess some personal egos have had also quite a big influence on such decision...

Funny, JBoss just announced EJB-3.0 preview release https://www.theserverside.com/news/thread.tss?thread_id=29318

This will definitely turn off potential new comers to JDO since its future uncertain now... I guess next step app.

Uncertainty is part of the job as architect and designer.
We have made good experience with having a thin wrapper around
the actual persistence solution.
We are training our developers on our persistence layer instead of a
specific technology and are able (to a certain degree) to switch
the technology without much impact.

We successfully moved from the proprietary versant JVI to JDO without
doing any major change to the codebase. Of course, developers need to
be made aware of some differences, but they are still using the same
API to work with persistent objects.

I expect to do another transition from JDO to whatever-comes-up-with-EJB3.0
in the not so distant future and we are not afraid about it.

Sure. That is the natural protection - thin layer to avoid tight coupling.

We have used DAO pattern that nicely hides persistence implementation. In fact I tried to instatiate via Factory different DAO implementations (JDBC based and JDO based)

However, we still need developers who actually have knowledge on the persistence API (since they will need to write DAL implementations for actual applications). If JDO is not mainstream, it is going to be hard to find "of the market" developers that would know anything about JDO. In opposite, there are plenty of developers that know well JDBC.

BTW, I do not consider EJB (CMP/BMP) as a persistence technology of my choice.

According to the Versant post the other day, 16 hits is the minimum possible. So what are you going to do when every vendor finds a way to rig their setup so that it comes out with 16 hits? As the vendors cluster around 16 hits, doesn't the while thing become increasingly meaningless?

The fact that 2 vendors have now achieved the best possible score does not detract from the value of the benchmark. The techniques used by Versant Open Access and Kodo are very applicable to real world applications. The benchmark has proved that JDO implementations (and O/R mappers) can produce very good SQL. There is a lot of FUD saying otherwise on the net.

The next step would be to benchmark real runtime performance for a sample application. This will differentiate the implementations with 16 hits with the ones with the least mapping overhead and most efficient caching doing well.

Cheers
David
Versant Open Access www.versant.com

David,

The next step would be to benchmark real runtime performance for a sample application. This will differentiate the implementations with 16 hits with the ones with the least mapping overhead and most efficient caching doing well.

I'd enjoy that, but what I'd really like to see are better validations that the implementation is actually keeping the object model consistent in the face of caching etc.

-Patrick

--
Patrick Linskey
Kodo JDO
SolarMetric Inc.

Once they all reach 16 getting performance numbers will help understand the efficiency of the mapping layers and thats good.

However, even more interesting is understanding the impact of an evolving db schema. Count the number of steps necessary to remap and redeploy the solution. Have a simple object model and "refactor it" to use inheritence and adopt interfaces that refer to any potential subclass. Understanding how the soultion facilitates the evolution of my model would be of interest to me.

8 is the best possible score, although hard to achieve :-)

If someone offers a $1,000,000 prize for a score of 8, I'll prove it is
possible :-)

14 is also achievable, much easier than 8

Congratulation Patrick ;-)

Your submission will contribute to gain favour to the JDO technology.

Congratulation again to you and your staff.

bye,
Luca Garulli
www.OrienTechnologies.com

According to the Versant post the other day, 16 hits is the minimum possible.

I agree that 16 is the theoretical minimum for a standard O/R mapping implementation, and not just because that happens to be our best number. However, I'd really encourage you to do your own fact-checking about what the minimum is -- it's really not a good idea to trust us vendors with things like that.

That's actually one of the big values of independent organizations like TMC. It'd be nice if they'd provide an independent analysis of things like minimum theoretical results for benchmarks like this. However, I understand why they didn't -- we didn't do special "rigging" to make Kodo get to 16, we just iterated on the tuning problem a couple times to see if we could find more opportunities to optimize. It takes a decent amount of analysis and thought to figure out what the theoretical minimum is, and TMC has already put in a lot of time and energy just getting the test suite out there.

-Patrick

--
Patrick Linskey
Kodo JDO
SolarMetric Inc.

Hi,

It would be great if the MiddlewareResearch could spend a little amount of time getting the download updated to reflect the latest changes including updating the build scripts and possibly providing pre-built ears/jars. This would reduce the effort of others trying to get the benchmark to work under the different environments and tools.

Regards,

William Louth
CTO, JInspired

"J2EE tuning, tracing and testing with Insight"
http://www.jinspired.com

Hi Patrick and David,

I'm confused. I thought Versant bought Solarmetric and KODO JDO.

Hi Gordon

For about 9 months, ending just before JavaOne 2004, Versant had a distributorship agreement with SolarMetric which allowed them to sell Kodo in certain territories. They spent this time telling the market how wonderful Kodo was.

Versant liked JDO so much that they decided to acquire an implementation, and they found that they could afford to buy JDOGenie. They spent the next 3 months telling the market how wonderful JDOGenie was.

They have now rebranded the product as Versant "Open Access" as seems to be the fashion these days. In fact, Kodo remains the only influential JDO implementation which has not undergone a corporate or product rebranding.

Kind regards, Robin.

It started as Tech Trader JDO many moons ago :-)
Yes I've been using it since then

In fact, Kodo remains the only influential JDO implementation which has not undergone a corporate or product rebranding..

Hmmm, JPOX could be considered "influential" in the Open Source world ... and we also haven't had a corporate or product rebranding recently either ;-)