Versant has made a new TORPEDO submission claiming new results that surge ahead of other submissions. The Non-Verified submission was made using Verstant Open Access 3.2.0 beta 8. This submission eclipses the previous best results held by BEA WebLogic Server.

Versant's submission totals 16 hits. It is a single server submission made with HSQLDB 1.7.2, the configuration file sets default-fetch-group on bids and item fields and adds fetch groups for the partial listing. The new bid creation was optimized to avoid extra reads.

This is the lowest number of hits possible since there are 8 tests and each test requires at least one query and one commit statement.

This additional quote was made by the Verstan Open Access team upon their submission:

Questions have been asked about the database portabilty of previous Torpedo submissions. We have tested Torpedo against some of the databases that Versant Open Access supports with consistently good results.

The following databases have 16 hits:

Oracle 8.1.7
Oracle 10.1.0 (10g)
IBM DB2 V8.1
MySQL 4.0.16
MySQL 3.23
Microsoft SQL Server 2000
Postgres 7.3.1
Hypersonic SQL 1.7.2 RC2

We do not use batch inserts for the following databases (due to no or buggy JDBC driver support) so they require one more insert (17 hits):

Sybase 12.5
Informix Dynamic Server 9.30.UC1
Informix Dynamic Server 7.31.UD1
SAP DB 7.4.3.17
Firebird 1.0.2

It is often claimed that SQL and JDBC are portable. Well even for the simple query used for the the find all auctions test we have to generate 4 different pieces of SQL. The situation is much worse in real applications that need to use subqueries and BLOB columns.

Oracle 8.1.7, Oracle 10.1.0 (10g), SAP DB 7.4.3.17

SELECT a.AUCTION_ID, a.ITEM, a.LOW_PRICE, a.SELLER, b.ITEM_ID, b.DESCRIPTION,
    b.GRAPHIC_FILENAME, b.ITEM_NAME, c.AUCTION, c.BID_ID, c.AMOUNT, c.AUCTION,
    c.BUYER, c.MAX_AMOUNT, d.USER_ID
FROM AUCTION a, ITEM b, BID c, AUCTION_USER d
WHERE a.ITEM = b.ITEM_ID (+)
  AND a.AUCTION_ID = c.AUCTION (+)
  AND c.BUYER = d.USER_ID (+)
ORDER BY 1

MySQL 4.0.16, MySQL 3.23, Microsoft SQL Server 2000, Sybase 12.5,
Postgres 7.3.1, IBM DB2 V8.1

SELECT a.AUCTION_ID, a.ITEM, a.LOW_PRICE, a.SELLER, b.ITEM_ID, b.DESCRIPTION,
  b.GRAPHIC_FILENAME, b.ITEM_NAME, c.AUCTION, c.BID_ID, c.AMOUNT, c.AUCTION,
  c.BUYER, c.MAX_AMOUNT, d.USER_ID
FROM AUCTION a
    LEFT JOIN ITEM AS b ON (a.ITEM = b.ITEM_ID)
    LEFT JOIN BID AS c ON (a.AUCTION_ID = c.AUCTION)
    LEFT JOIN AUCTION_USER AS d ON (c.BUYER = d.USER_ID)
ORDER BY a.AUCTION_ID

Informix Dynamic Server 9.30.UC1 and 7.31.UD1, Hypersonic SQL 1.7.2 RC2

SELECT a.AUCTION_ID, a.ITEM, a.LOW_PRICE, a.SELLER, b.ITEM_ID, b.DESCRIPTION,
    b.GRAPHIC_FILENAME, b.ITEM_NAME, c.AUCTION, c.BID_ID, c.AMOUNT, c.AUCTION,
    c.BUYER, c.MAX_AMOUNT, d.USER_ID
FROM AUCTION a
    LEFT JOIN ITEM AS b ON (a.ITEM = b.ITEM_ID)
    LEFT JOIN BID AS c ON (a.AUCTION_ID = c.AUCTION)
    LEFT JOIN AUCTION_USER AS d ON (c.BUYER = d.USER_ID)
ORDER BY 1

Firebird 1.0.2

SELECT a.AUCTION_ID, a.ITEM, a.LOW_PRICE, a.SELLER, b.ITEM_ID, b.DESCRIPTION,
    b.GRAPHIC_FILENAME, b.ITEM_NAME, c.AUCTION, c.BID_ID, c.AMOUNT, c.AUCTION,
    c.BUYER, c.MAX_AMOUNT, d.USER_ID
FROM AUCTION a
    LEFT JOIN ITEM b ON (a.ITEM = b.ITEM_ID)
    LEFT JOIN BID c ON (a.AUCTION_ID = c.AUCTION)
    LEFT JOIN AUCTION_USER d ON (c.BUYER = d.USER_ID)
ORDER BY a.AUCTION_ID

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

The TORPEDO Launch Discussion.
The Oracle TopLink Discussion.
The BEA WLS Discussion.

Just to clarify the post: This submission was made with the Versant Open Access JDO product (previously called JDO Genie).

Cheers
David
Versant Open Access - www.versant.com

Congratulations, David .. also, I like the example given above about differences between engines and how your software automatically can handle it. It would be nice (hint hint) to get Gavin, some JDO reps, Vic etc. onto a panel for the next TSS symposium to discuss database-based development, and some of the challenges / solutions for it.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

It would be nice (hint hint) to get Gavin, some JDO reps, Vic etc. onto a panel for the next TSS symposium to discuss database-based development, and some of the challenges / solutions for it.

It is definetely a real show case of JDO technology!
I hope that EJB3 group will allow all relevant JDO experts to join!

Congratulations for the very flexible and customizable JDO product you have.

After a quick analyse of the difference, the two differences between Versant at 16 hits and the other at 22 are:

1/ Use of batch insert like they explain it themselves. It allows Oracle to claim to be at 21 hits. Hibernate and I think most ORMs support it. It just depends on the underling database.

2/ Use of proxy. In AuctionServiceBean, we have:

User user = persistentAuctions.getUser(userID);
Auction auction = persistentAuctions.getAuction(auctionID);
Bid newBid = persistentAuctions.createBid(bidID,auction,user,amount,maxAmount);

Hibernate returns a proxy (an empty lazy-initialised object) from getUser() and getAuction(). But this proxy is initialise in the Bid constructor because the call to the property getBids() on auction and buyer :

public Bid(...) {
  ...
  auction.getBids().add(this);
  buyer.getBids().add(this);
}

These initialisations make a hit to the database that is not really necessary. Hibernate should not initialise an object when a call to property one-to-many is made, like it currently do not when we call a primary key property. I will post a bug in Hibernate JIRA to follow this up. There is a way to make a work around to avoid these initialisations, but a correction would be prettier.

Adrien

But this proxy is initialise in the Bid constructor because the call to the property getBids() on auction and buyer :
public Bid(...) { ...
  auction.getBids().add(this);
  buyer.getBids().add(this);
}
These initialisations make a hit to the database that is not really necessary.

You realize that the getBids() collections has to be loaded to fully respect the Collection.add() semantic if Bids are neither List or Bag.

You realize that the getBids() collections has to be loaded to fully respect the Collection.add() semantic if Bids are neither List or Bag.

Hum, actually neither indexed collections or Bags

But this proxy is initialise in the Bid constructor because the call to the property getBids() on auction and buyer :public Bid(...) { ...   auction.getBids().add(this);   buyer.getBids().add(this);}These initialisations make a hit to the database that is not really necessary.

You realize that the getBids() collections has to be loaded to fully respect the Collection.add() semantic if Bids are neither List or Bag.

Exactly. In my opinion it's serious flaw in Hibernate. Ok, I know they just want to be 100% compatible with Set.add contract, but in 99,9% of real situations the return value is of no use. Is there any way to make this behaviour configurable in Hibernate? Perhaps property (on configuration or class level) to break this compatibility just for sake of performance...

What serious flaw? Thats what Bags (AFAIK a unique Hibernate feature) are for and you don't even need weird static FooHelper.close() or some similar housekeeping method if you work with collections.

Is there any way to make this behaviour configurable in Hibernate? Perhaps property (on configuration or class level) to break this compatibility just for sake of performance...

Use a java.util.Collection or List mapped as a <Bag ...>
This is way better than any breaking-the-rule strategy

The placeBid and place2Bids operations have 2 hits each (insert and commit), but the testcase needs data from database to create value in the insert statement. Where do your values in your 'INSERT' statement come from?

They can't come from database since you don't have 'SELECT' statement.
They can't be in cache since the app server needs to restart. The benchmark requires that the app server be restarted before each operation.

Where do your values in your 'INSERT' statement come from?

Hi Michael

Bid references an Auction and a User and has amount and maxAmount fields. The Auction and Buyer are looked up using the JDO call pm.getObjectById(oid, false). The false flag is a hint to the implementation that it is not required to validate that the instance exists in the database. So we dont have to read anything to create hollow instances that can be assigned to the references in the Bid instance. Note that actual instances of Bid and Auction are created, not proxies.

The bids collections on Auction and User do not have to be read as they are mapped using an inverse foreign key i.e. the auction and buyer references respectively. All we have to do to add the Bid to the collections is set these back references to the hollow instances. When the tx commits the correct insert is generated. When the Auction and User instances are re-read at some point the collections will be correct.
 
So we end up generating exactly the same SQL that you might write by hand with standard JDO code.

Cheers
David - Versant