<quote>
By the time Sun realized its mistake, it was too late: JDO was competing against EJB and the customers became more confused than ever.
</quote>

Where did you get that? JDO does not compete with EJBs *in general*, that's obvious to anyone who browsed through EJB and JDO specs. However, many people see JDO as an alternative to EBs.

<quote>Sun never explained in a convincing manner what their position was, except maybe by being clear on the fact that as of today, there was no plan to include JDO in J2EE.
</quote>
I think eventually Sun will include JDO into J2EE. Not necessarily the first version, but JDO spec appears to make more sense than EBs, in my opinion.

<quote>First of all, advocating BMP to push a persistence mechanism is a huge step backward to me, and I don't think I need to explain why it is a bad idea to suggest to customers that they should implement their own transaction marks, handling rollbacks, etc... But most of all, when showing different pieces of code illustrating the different approach (CMP vs BMP/JDO), the difference wasn't very striking to me.
</quote>

I highly doubt that people who are using JDO will be using EBs at all. A possible usage scenario could be SLSB (remote access, security and etc) + JDO. I do not really see any benefits of using EBs with JDO but I do see several good arguments why one would want to use JDO instead of EBs.

<quote>
I can't really understand why Craig thinks that EJB users will be thrilled to use BMP and JDO, but maybe I'm just missing something.
</quote>

I think the he&#8217;s trying to show that EBs and JDO *could* be used together, for 'political' reasons. IMO, once one decides to use JDO there is not really any need for EBs.

I don't want to sound cynical, but it appears that BEA is spreading a lot of FUD about JDO (based on my couple of meetings with BEA reps). This is somewhat understandable due to BEA's investment in EBs, the app server
and the fact that JDO (contrary to EBs) can be used with or without an app server.

I believe that, as politically incorrect as it sounds, JDO, in the long run, should replace entity beans completely. Anyone who has actually used JDO (or its predecessor, ODMG) to do real work, knows that there's no going back.

The beauty of JDO is that there is now a Java standard that lets object models remain focused on the model, minimally affecting the source code (not the bytecode, though). Any object model that is designed to be persisted in a data store reflects that fact. With JDO, this is no exception, but very few restrictions are placed on the JDO-persisted classes, unlike the restrictions placed on entity bean classes.

Additionally, the clients of the JDO-persisted object model (session beans, message-driven beans, or servlets in J2EE), have some JDO code in them, much like clients of entity beans have entity-bean code in them.

- Sun demonstrated a couple of rolling robots battling to push each other out of a Sumo wrestling ring. Behind the scenes the robots demonstrated how far Java has come. A friend in the computer industry recently asked me “Is Java for real?” The robots had a administrative console built in J2ME that runs on a mobile phone, the console communicates with a Java-based application server running an EJB, the EJB packages and sends operating instructions to the robots over a wireless TCP/IP connection and the robots running embedded Java kick-ass over a human operated robot. J2ME, J2SE, J2EE, Servlets, Filters, Security, etc. Java is mature.

- CapeClear combined the CapeStudio and CapeConnect developer tools into CapeConnect 3.5. This makes CapeConnect a very powerful tool for enterprise developers in heterogenous shops that need to bridge Corba, Com, RMI and SOAP. Details at http://www.capeclear.com.

- David Chappell & Tyler Jewell’s new ORielly book “Java Web Services” made its debut at JavaONE this week. The book is really very good. In 260 short pages the book covers SOAP, WSDL, UDDI and then goes really detail in covering Apache Axis, JAXM/SOAP, XML-RPC and the new Signatures security system. David runs Sonic (http://www.sonicsoftware.com.) Sonic launched SonicXQ which delivers a Java Connector Architecture (JCA) implementation.

- “You mean Borland has an application server?” asked another friend. Borland has been so quiet that it has been easy to miss that Cisco is now entirely using the Borland Enterprise Server to host J2EE and JSP applications. The new JBuilder and Borland Enterprise Server deserve another look at http://www.borland.com.

- Sprint showed off a hot new tri-band mobile phone that runs J2ME Midlets - “Midlets, what are midlets?” The phone has an incredibly sharp color screen in 120x160 pixels. Sprint will offer developers it’s billing system - so developers can offer ecommerce functions in a midlet that runs on the phone. Purchases then get billed to the Sprint customer’s phone bill. Nice. A developer package is available at http://developer.sprintpcs.com.

- Your’s truly showed off TestMaker, a utility to developing intelligent test agents to assure Web services and Web applications for functionality, scalability and performance. TestMaker is distributed under an Apache-style open-source license at http://www.pushtotest.com.

Another good source of opinions is on Iona's web site at http://www.xmlbus.com/rant. This is a site that offers a good alternative opinion to EJB and Web Service development using Java. The opinion appears as a 1960's left-wing radical anti-war leaflet. It brings together why none of the individual initiatives (EJB, JDBC, SOAP, JCA, etc.) are going to provide developers with enough technology to deliver an interoperating solution. It's worth a read.

Well, I am not sure what benchmark information you would like to see. You can theoretically achieve any performance you get in CMP by using BMP. The only difference is that you have to write all the persistance code (what CMP is all about avoiding).

Not only do you not have to write any persistance code, if you use CMP with any decent container, you get a number of big performance enhancements "for free":
+ Tuned updates (only writing the changed data - no write at all for a read-only operation)
+ eager-loading (pre loading an object graph - related to caching)
+ lazy loading (loading large expensive fields in a JIT manner)
+ switch between optomistic and pessimistic concurrency
+ caching (multiple calls on the same bean within the same transaction with only one database read/write)
+ distributed caching (for some containers)

You can obviously achieve any of this with BMP. However, you have to code it, test it, debug it and maintain it. Its not trivial to do. Its very easy to have a buggy implementation unless you have very experienced people.

The performance difference you will see between BMP and CMP greatly depends on your application. In general, a CMP implementation will give much better performance and (more importantly) more reliable code for a lot less work.

Basically, you should only use BMP if CMP cant work (e.g. legacy constraints). If CMP doesnt deliver the performance you require, then it is going to be rare that switching to BMP, and doing all of the optimisation manually, will actually help.

>>.. but not vise versa.
It comes down to who is the better persistance layer programmer. Someone at Borland or BEA or Webgain (Toplink) whose business is writing this stuff.... or John Doe programmer for Acme eBusiness corp, who is writing a Bonds Trading system.

The point was that in most cases, a non-trivial amount of work is required to get BMP to achieve even similar performance.
It is generally true that using BMP, you will have reduced maintainability, and it is likely to be less reliable. This becomes increasingly true once you have to hand-craft lots of optimisations.
Generally, using JDBC from session beans gives you more scope to optimise DB access than via BMP.

>>Providing that you access an instance of your EB by PK.
>>Otherwise, back to the db we go ...
Partly true (you are absolutely correct when referring to finder methods hitting the cache. This is true for any object cache.)
I was referring to calling a number of methods on the same bean in the context of the same transaction (e.g. personCMPBean.setPostCode() followed by personCMPBean.setStreetAddress()). In this case, using CMP, you can configure the container so only one database write will occur - on the tx commit.

>>I do not think you can do that in WLS 6.
Correct. I think Borland Appserver now supports both (and WLS7 is supposed to as well)

<quote>
Partly true (you are absolutely correct when referring to finder methods hitting the cache. This is true for any object cache.)
</quote>

One of several things I like about JDO is that it allows you to run queries agaist cache regardless of if a query is by PK or by non-PK attribute(s). This makes JDO cache, from the start, much more useful that EB's cache. Whatever.

<One Way>
One of several things I like about JDO is that it allows
you to run queries agaist cache regardless of if a query is
by PK or by non-PK attribute(s). This makes JDO cache, from
the start, much more useful that EB's cache. Whatever
</One Way>

Ok, this is interesting. How can it do this?
If there is an external system also accessing the database (v.common), then the object cache must always go to the database on a non-pk query (there may have been new inserts).

<quote>
Ok, this is interesting. How can it do this?
If there is an external system also accessing the database (v.common), then the object cache must always go to the database on a non-pk query (there may have been new inserts).

NB: Not even Toplink can do this...
</quote>

Craig Russel: "If you use the form of Query that takes a Collection instead of an Extent, then you will run queries in memory and not in the DB (unless of course the instances in the Collection are not instantiated in memory)."

>> unless of course the instances in the Collection are not
>> instantiated in memory

This doesnt sound too promising.

As far as I am aware, it is not possible to run non-PK queries against the cache if there are other systems that make inserts into the database. Optimistic locking can help with updates from an external system, but there is no mechanism to detect inserts (NB: This is a specific O-R issue. JDO is a generic persistance spec - that doesnt detail this O-R problem)

I will need to refer to the spec to work out what your quote means exactly.

I disagree. EJBs have no such capability at all, so JDO is definitely more promising in this regard.

<quote>
As far as I am aware, it is not possible to run non-PK queries against the cache if there are other systems that make inserts into the database.
</quote>

Obviously, it’ll not work for systems where several independent apps have an option of updating db directly, but then what will? If the apps could somehow share the same Persistence Manager, it may even work in that case.

I wasnt suggesting CMP did have this capability. I was just concerned that some false promises were being made of JDO here. (there are a few of these sorts of claims going around)

Almost all persistance is done to a relational database.
Most servers are clustered (if not for load, then for availability).
Therefore; a) the same persitance manager cannot be used (different JVMs).
b) the db will always be modified by an external system (the other Persistance Managers)
Wiring up the caches wont fix this either for inserts - unless you make the cache updates transactional (which puts an end to performance and scalability).

Therefore, for most*most=most^2 applications, you cannot run non-pk queries without hitting the database.
While I am no JDO expert, I get a bit suspicious when there are claims made that "JDO" can do stuff that I know the mature O-R mapping tools cant do.

I attended Tyler's session. Definitely one of the better sessions, but I sensed a different feeling than Cedric. The audience certainly was charged, but I would say that was because Tyler was saying quite a few controversial things without qualifying them all that well, and a number of people weren't very pleased that there wasn't a Q&A session to clarify these points.

As an example, the comment to "never use lazy loading" must be carefully coupled with the suffix "when you're using multi-object finders for immediate data reading". In his defence, he qualified the statement by suggesting that "batch writing would require lazy loading", but in an off-hand way that this really doesn't happen all that often... on the contrary, by my experience: any record or document oriented system has an "edit" feature where you send a snapshot of the data to the client, and must send it back to the server for update (and usually an optimistic lock check). Such an operation doesn't require a re-read of the data fields -- at best it requires a primary key existence check and a WHERE clause to cause database to compare the optimistic locking fields.

Another note is that the spin on the JDO session is problematically biased. I don't think it reflected the audience's mood, it more or less was a rant against JDO. Having said that, part of me certainly agrees with Cedric (We've worked damn hard to get CMP to work, only to shun it? Aren't BMP multi-object finder methods still useless? Does JDO have any real support?)... but part of me really likes JDO, there's something to be said for the persistence model like that (and, I *do* like writing my queries in Java when they're dynamically composed because it's safer than composing a SQL string together.. nevertheless if dynamic EJB QL becomes a reality I could live with that..)

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.