Subject:   "Castor JDO": Simply False Advertising
Date:   2002-12-16 11:49:03
Response to: "Castor JDO": Simply False Advertising

Hi Sundar

Firstly, thanks for posting under your own name instead of anonymously. It is easy for readers to dismiss the credibility of anonymous replies.

I had a look at your site but found no "category" for object-relational mapping or relational database access. Are your views on this subject covered under another topic?

SQL allows field-level access to data. As such it is a very efficient API, its only big drawback being the lack of syntax-checking available for SQL at java compile time, which itself is quite understandable.

If you like working with SQL and believe it is no hinderence to your application development efforts you should probably continue to use it.

However, if you feel that:
1. Your SQL development is time-consuming, or
2. Your home-grown infrastructure is not sufficiently flexible (e.g. lack of true polymorphism), or
3. Your applications depend on the presence of a relational database when another paradigm may better suit some deployments (e.g. binary file, ODBMS, etc), or
4. Your SQL infrastructure is making your domain model inflexible (field names matching column names, and classes not spanning multiple tables, would be prime examples), or
5. Your SQL infrastructure is "castrating" your object model (value objects with little domain-specific behaviour, but lots of load-save-from-db behaviour), or
6. Your SQL infrastructure requires developers to have a significant level of skill in (a) SQL and (b) your proprietary infrastructure, or
7. Your application is based on an infrastructure known in detail by only one or two developers who might (a) leave or (b) make excessive wage demands (I put that one in for fun!)

...then you should consider JDO.

JDO provides a standard infrastructure that:
1. Is a standard, and
2. Is widely implemented by vendors competing on Quality of Service, and
3. Enables applications to be independent of data store paradigm (relational DB, object DB, etc.), and
4. Still lets you use SQL if you wish (the Query interface lets you specify a query language other than JDOQL), and
5. Provides "Transparent Persistence" - for more info read my book "Java Data Objects" in paperback or PDF, or email me, and
6. Deploys in a client-server, web, or enterprise context, with all the scalability characteristics you'd expect (particularly on the web/enterprise tier), and
7. Is really cool (I put that one in for fun too!).

No-one said you must use JDO...but I suggest that those who employ JDO wisely will have strategic advantage in software development over competitors who do not, which could be cruicial in the current IT marketplace.

And if you do choose the JDO standard, remember to exclude so-called "Castor JDO" from your evalautions! Ok, I think we've rammed that one home now ;-)

Kind regards, Robin.
Robin M. Roos

Full Threads Newest First

Showing messages 1 through 1 of 1.

  • "Castor JDO": Simply False Advertising
    2004-03-16 18:04:27  tksrajan [View]


    The problem that I have faced when using third party frameworks (JD, ORM, others) are

    1. Bt their very nature, they tend to include code that I might never have any use for, but which can contain bugs. So I have to be often clever enough to bypas the bug(s) , but yet extract the required functionality

    2. Very little documentation when they are open source.Whatever documenation there is, normally talks about only what works and very often you would want to know about what does not work.Here is a case in point.

    If you hav used JBOSS MQ series(I am refering to the one bundled with JBOSS 3.0.8) , there is a strange problem. A QueueListener that you have registered receives messages whenever some code posts a message to the Queue.This is normal behaviour. However,if JMS server node restarts for whatever reason, the connection factory and connections are stale and so we obtain fresh connection after closing the old listener.We are still able to receive messages on the new connection.

    However there is a clock daemon that runs(don't know where, possibly inside the listener?) which checks for the validty of the connection and throws some spyJmsException every one minute with a message that the ping task failed etc.This is fine when JBOSS is down.But this stacktrace is printed even when normalcy is restored.

    You might ask, so what is the big deal? It works , does it not? Yes, but if my UAT is dependent on my showing a clean log to the client after a 12 hour load test, I need to hack the log4J file so that the messages emitted by the [Connection Monitor Thread] of JBOSS are not logged at all

    Even the $10 documentaion of JBOSS does not contain any reference to this

    So I will state my point slightly differently

    1. If you have the money, go for an implemenation or framework that you know will be supported or that (even open source) where you have extensive experience

    2. If you don't have the money, build one yourself. Simple , initially just concentrating on your immediate needs and slowly developing this to a full fledged framework