|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
EJB design
EJB design
EJB design
|
Messages: 190
Messages: 190
Messages: 190
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Java Data Objects vs. Entity Beans
I have been really interested in Java Data Objects specification as an alternative to using entity beans, and I would like to open discussion about this topic.
It seems to me that Java Data Objects are what Entity Beans should have been like. Consider the purpose of entity beans:
1) Provide a standard way to persist your domain model
Before entity beans, people had to write their own persistence frameworks or rely on proprietary relational mappers.
2) Encapsulate the persistence mechanism
BMP or CMP? Persistence mechanism should be hidden behind the entity beans.
3) Be distributed objects, callable from anywhere
IMHO, this feature was a big mistake.Entity Beans should not be accessed remotely, to wrap entity beans with session beans is a common design pattern.
4) Be transaction aware objects
Since entity beans should be wrapped by session beans, it is not necessary to set transaction settings on entity bean methods since the transaction settings will be determined by the calling session bean.
Entity Beans do a great job at #1 and #2 above, but because the mistakes made by EJB designers in providing #3 and #4 above, entity beans are wasteful because they use distributed network calls, even though most people wrap them with session beans, they add transactional overhead and require transactional deployment descriptor settings, again even though most people wrap them with session beans,
Entity Beans require a lot of extra coding to make them worthwile, such as implementing details objects.
Java Data Objects seem to be what Entity Beans should have been. Simple, plain java classes that provide benefits #1 and #2 in a much simpler and better way than entity beans do, and don't even try to offer #3 or #4, thus using java data objects will be dead simple. Imagine, no more stupid long deployment descriptors, no more JNDI lookups to find a simple domain model class, no more brainless gets and sets to for details objects, etc etc.
I havn't used JDO (its still a JSR) but this is what I gather from reading up the spec. I would like to open this discussion to other members and get some input from you.
Floyd
|
|
|
Message #2341
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Floyd,
I wholeheartedly concur with your assessment of entity EJBs and their suitability to more typical data access/management tasks. A common refrain I hear when developing data-oriented systems goes something like "But, how are you doing persistence? You can't possibly be using entity beans..." -- implying the serious overhead costs incurred because of items #3 and #4 in your post.
JDO may be the answer eventually, but I'm curious to hear how others are solving the problem right now (if they are). We've written our own persistence/cache layer, which is a signficant investment that in the end we'd prefer not to have to make. It gives us lots of flexibility in developing the rest of the application, but the price is we have more than enough rope to hang ourselves with and we're at the top of a slippery slope of adding more and more custom functionality (I think that's enough metaphors for a Friday).
Dan
|
|
|
Message #2343
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Dan,
Don't get me wrong, my post was not an attack on entity beans, it was a suggestion that JDO is better. Although entity beans were not that well designed from the start, I am still a fan of using them in some situations. Due to app. server caching, entity beans are actually a lot faster than alternatives when you are frequently reading the same data from a database (see Coarse Grained entity beans vs fine grained entity beans).
In terms of alternatives, rather than writing your own framework, I have heard that people are really enjoying using relational mappers like TopLink, CocoBase, or OODBMS like Gemstone.
Floyd
|
|
|
Message #2345
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Although not specifically targetting the JDO spec, the Castor project's JDO implementation will give you a preview of one way this technology may evolve. The mailing list for this toolkit is very lively.
http://castor.exolab.org/
Mike
|
|
|
Message #2359
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
How do JDO objects handle concurrency. My guess is they don't, which pushes concurrency responsibility to the database. In effect, any *good* EJB container does the same thing due to multiple entity beans per VM, or in clustered server configurations.
<p>
With that said, I spend a fair amount of my BMP code, managing the concurrency demands of my application. Does JDO provide the necessary hooks to do the same? For example, if I want to use a timestamp column (or similar technique), can I?
|
|
|
Message #2379
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi Floyd,
I believe JDO is eventually the way to go - I'm not sure how at this point. The questions concern abstraction, performance, scalability, and just getting everyone on the same page. Since there are more than just a few people involved, this may take some time.
If you're using BMP, a simple answer is just use JDO within the EB instead of (or on top of as the case may be) JDBC. This abstraction enhances re-use - in the same way as the zzzzDAOxxx classes in the Pet Store example - but with the added benefit that the underlying storage structure is abstracted.
Here's what Pet Store does: In Pet Store, they use OrderDAO to implement a SQL interface and then allow implementation of different RDBMSs.
Using JDO, the idea is the same - only the data source can then be an ODBMS (Versant JUDO+Enjin for instance) or anything Castor (exolab.org) supports, or an RDBMS.
This also keeps the EB concept intact so you still get scalability. You could get scalability wihin the JDO provider of course, but this kind of performance solution is equivalent to JDBC connection pooling: performance is maintained outside of EJB.
In CMP, the problem is more complex. At this point, my inclination is that CMP may need more maturity - but here again, JDO might help in implementing CMP.
So maybe, EBs and JDO can work together? So far, the only adverse reactions I've received from this idea came from a relational database programmer who didn't see the need for using anything except their own particular RDBMS and wondered why I would want to even use an ODBMS (also, he was trying to learn EBs by looking at Pet Store and he felt the additional SQL class was too distracting to begin with).
Thanks for bringing up the question. It's good to know someone has been thinking about JDO.
Just some thoughts.
Regards and best wishes,
Rich Katz
Java Skyline
|
|
|
Message #2387
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
The way I see it, the question of checking for concurrency via checks against the database isn't going to go away unless the spec mandates for a shared object cache across multiple servers. Since this hasn't happened yet (and may never) any persistence mechanism is always going to need manual code to do this type of check (timestamp, full data comparision, whatever).
Which brings me to two points:
a) CMP is great in theory but has never addressed this concurency problem. JDO doesn't look like it will either
b) Floyd's right. JDO looks like what Entity Beans should have been. It may be quite a while before the performance of JDO vs. EB is decided. Why did SUN put out such an immature perstistence mechanism out there ? EJB 1.1 mandates Entity Beans, EJB 2.0 mandates JDO. EJB 2.1 mandates ??? As an enterprise system designer I'm amazed at how such a fundamental aspect of design (systems are process and DATA) can be left out. I think that this issue is going to restrict adoption of EJB at an enterprise acceptance level.
|
|
|
Message #2391
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
In our discussion, we should keep in mind that JDO isn't anything new, really. Its just a standardized API for java object persistence. There have been tools on the market for quite a while that have implemented similar APIs on top of relational databases (e.g. TopLink, CocBase, etc.).
Having written such a framework myself, I was indeed amazed at the naivete with which the EJB designers appoached persistence. I remember back in the days when a proposal for the CORBA persistence service was finally dropped because everyone (from among the ODBMS experts) agreed that adding the overhead of remote accessibility to every persistent object was meaningless and unacceptable in terms of performance...
|
|
|
Message #2439
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
A few points:
1. EJB-2 does not mandate JDO (the query language issue would have been resolved, if it did); it introduces the notion of CMRs (container-managed relationships). These are a poor man's version (when compared to JDO) of managed associations between persistent objects.
2. Yes, at some point, EJB should look at adopting JDO for fine-grained persistence. The extensive use of interfaces by JDO, allows for a JDO implementation to provide any arbitrary persistence store for JDO objects.
3. For "optimistic transactions" refer to section 5.8 of the JDO specification. Products such as "Judo", Versant's implementation of JDO (http://www.versant.com/developer/judo/index.html), have built in support for traditonal (pessimistic) as well as optimistic transactions (leveraging automatic timestamp checking for cached objects being committed).
|
|
|
Message #2662
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
I fully agree with you . The Deployment Model of EJB is
nothing but Java Data Object. I think Sun started the MicroSoft Way ,
Balaji Venkatraman
Chief System Architect
|
|
|
Message #2747
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans, usage issues
From a performance perspective, I wonder what sort of caching can be acheived with JDO, and how much of it will be able to be abstracted to the container. For example, I find that entity beans are faster than alternatives when frequently reading the same data, due to entity bean caching in the app. server. That is really the only effective advantage of entity beans over alternative frameworks or coarse grained persistence.
Does JDO allow for one cache of objects per app. server, or even per cluster? From the JDO spec, it sounds like each "Manager" maintains its own separate cache of JDO objects, which is not as good as application server wide caching that entity beans can provide.
Any interfacing of JDO with CMP is the containers responsibility, and would be hidden from the programmer. From a developers point of view, we should be interested in how to use JDO wrapped with session beans. In particular, in this scenario, how can we:
1) abstract transaction demarcation to the container, when using JDO? (will it be automatic like it is with entity beans?)
2) hide JDO API calls from our session bean business logic? Will there be some standard method, or should we turn to known Design patterns like the Factory pattern?
3) achieve the same level of caching performance that read-only entity beans can achieve?
If I know the answers to these questions, I think I will become a JDO Zealot. :)
Floyd
|
|
|
Message #2754
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans, usage issues
This rather lengthy response attempts to address the several issues raised ...
1. Caching in JDO
Caching in JDO provides for sophisticated multi-level caching.
a) Each Persistent Manager maintains its own cache of persistent Java objects. When dealing with read-only cached data, the same PM cache can be accessed by multiple clients concurrently. These clients could be session-beans "attaching" to the right persistent-manager to read data.
b) A JDO implementation is free to build a data caching layer that maintains its own private transactional caches. This "data caching" layer is free to cache a SQL result-table or a byte-stream returned from the database server.
c) For caching across app-server instances, an application can choose to use a JDO enabled "persistent cache". Several of customers are already building architectures that leverage an object-database as a shared persistent cache for multiple app-server instances.
2. Fine grained caching
Furthermore, with JDO, one has the flexibility to use Collections to access the cached objects as appropriate to the access methods required by the application. In other words, there is more fine grained control over caching provided to the application when compared to the entity bean model ... where the container (or persistence manager) determines this completely.
So, a JDO application could maintain a HashMap of MailBox objects keyed by mailbox-id. It could also maintain an ArrayList of most-frequently accessed MailBox objects. It can also cache a graph of related objects (such as Folders) that can be accessed from the root MailBox objects.
While it is possible to maintain these for entity-bean references, it is more convoluted than it should be; a session bean would need to maintain such collections for the entity beans. Issues would be caching of referenced objects ? duplication of cached objects in each session bean instance ? etc.
3. JDO interfacing with Container
The transaction coupling (using JTA) will be transparent to the developer. This is no different than what is done today (in EJB integrations with ODBMSs ... such as VEC - Versant's integration with Weblogic & WebSphere).
Typically, the EJB developer would not need to make JDO calls in session-beans (given the transparent nature of the JDO API). Where this is not the case, is when applications need to have more fine grained control over locking or transactions (such as explicit transactions). Also, where the default semantics of transparently fetching objects referenced objects is not adequate; for example when fetching graphs of related objects.
The EJB-JDO integration would ensure that the typical finder-methods ... are mapped to corresponding JDO queries. If an application needed to leverage query support that is not exposed thru EJB finders, then again the developer would need to understand how to formulate and execute JDO queries.
cheers,
Nipun
|
|
|
Message #2797
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans, usage issues
Please check out the JDO public access Web site
JDO supports arbitrarily flexible caching by the PersistenceManager (PM = high level abstraction of the JDO implementation).
A central design choice of JDO is that the PM decides how and when to cache information. The PersistenceCapable (PC) instance has fields defined in it to allow the PM to cache values. The PM has to choose whether to cache values per user-visible instance or to cache values across the entire data source (PersistenceManagerFactory) and retrieve these values when neededed. The enhancement process modifies the class to make it manageable by the PM. So there should be no issue that the PM can maintain a data source level cache for any information.
The PersistenceManagerFactory has an abstraction of what the EJB Connector Architecture calls the Connection Factory. A PM gets a connection from the CF, which in the application server environment should be transactional in the user's transaction. See the ConnectionFactoryName property in PMF.
Specific to your questions:
1. The PM should register for transaction completion callbacks with the container. The user should not have to do anything.
2. I don't know how to completely hide JDO from Session Beans [or why you would want to ;-)]. You could define a PersistenceManagerFactory (PMF) as a named (JNDI) resource, look it up, and get an instance of PM from it. The PM would be stored as an instance variable in the Session Bean.
The PM is the single interface required by persistence aware applications such as Session Beans. From the PM you control life cycle events for PC instances and query the data store using an Java-like query interface.
That said, the "business logic" of the Session Bean would not normally have to deal with the PM API.
3. You can certainly implement read-only Entity Beans using JDO. But you don't have to be constrained to the Entity Bean pattern.
You can use a JDO PM as a caching data store, with references from "any" Java instance to the persistent instances. JDO permits but doesn't require transactional access to instances.
With JDO, persistent instances are associated with transactions (via their association with the PM). Threads are not associated with transactions, so you can transparently use threads with JDO instances.
With JDO you can have an entire graph of persistent instances that can be accessed from any thread. You can even set it up so that the object graph is partially instantiated and dynamically and transparently populated from the data store, all without requiring transactional data access. This feature of JDO is called nontransactional access and is supported by persistence capable instance states, APIs, and flags.
|
|
|
Message #2798
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi Jim,
JDO defines two flavors of concurrency: Optimistic and data store. The specification doesn't define what the implementation must do, but does define what happens to instances when the optimistic assumptions are false at commit time.
JDO does permit the implementation to manage concurrency in data store specific ways, such as timestamp column or concurrency groups. These techniques presumably are hidden by the implementation from the user. The columns to use or the concurrency groups to use for a persistence capable class would be defined by the implementation-specific deployment tool.
|
|
|
Message #3373
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Floyd:
This is regarding the LiveChat about EJB2.0 today. Can you summarize EJB2.0 spec author's reply to this topic regarding the use of DAO objects vs the CMP Entity Beans ?
This would benefit all us and I believe this is very moot point.
Thanks very much.
-Sunil .K
|
|
|
Message #3410
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Performance/Scalability issues in JDO and Entity Beans?
It seems to me that you will have performance/scalability issues if you use either of these stateful technologies. Does anybody know of any research that shows performance/scalability data of stateless vs. non-stateless techniques.
It may be that keeping state at the http session or in a database is the best choice.
|
|
|
Message #3435
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Sunil,
When the transcript of that chat gets published, I will summarize it in a news article on the front page (I never actually recorded what was answered, I just remember that I was not satisfied with their answer.
Floyd
|
|
|
Message #3443
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi Floyd,
The transcript is now available.
I'm sorry I didn't get the chance to ask those questions about EJB + JDO, but I now think I would have been disappointed by the answers anyway... I found Craig Russel's posts here loaded with hope compared to those from the EJB 2.0 architects.
Cheers
|
|
|
Message #3473
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
I agree. The response on javalive to my question was silly. JDO is more powerful then entity beans, to use them behind an entity bean in a BMP manner doesn't add any value/performance enhancements, other than not writing JDBC. I suppose that it would be politcally incorrect for the authors of EJB 2.0 to admit that JDO is better, so I understand their position. Alternatively, it is possible that they answered the way they did simply because JDO is so new and they simply don't know that much about it.
Either way, I agree with you Franck, Craig Russel (spec lead for JDO) has pointed out that JDO access from session beans will be entirely possible and almost as user friendly as accessing entity beans.
Floyd
|
|
|
Message #3927
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
[Preface: I have yet to read the JDO spec, but this discussion certainly has put it on my short list.]
Hmmm. I think JDO and EB are apples and oranges. Entity Beans are not just rows in tables (or objects in OODMS'). EB's can be a sequence of COBOL programs executed on an OS/390 mainframe, an Active X object called via a CORBA Broker, an XML EDI message, all kinds of things. I don't *think* a JDO implementer would want an implementation for each thing an EJB can be. That's the Container/Server Provider's job. Can a Provider use JDO under the covers? Not a bad idea. Can they then expose JDO in the Beans themselves? Maybe. It would be in addition to the spec now, but how about an ejbx package? :-)
Michael
|
|
|
Message #4105
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Floyd:
I have some thoughts about your comments 3 and 4.
You said EB should not be remote. However, database venders are developping their own JVMs and Application servers, like Oracle. These application servers can have EBs which wrap Java object accessing data directly inside database. So we can have database related EBs and session beans in the database application server. Those beans should be remotely accessed by other businuss logic session beans in another application server. This means we can talk with database machine through RMI/EJBs instead of JDBC/SQL. Then this means EBs should be remote accessed and be transaction aware. Is this idea wrong or right?
|
|
|
Message #4117
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Yang,
Oracle had a good idea, put the data access logic on the same machine as the database, but this really has nothing to do with the fact that entity beans should not be remote objects.
As I mentioned in my post, pretty much everyone developing EJB applications are wrapping their entity beans with session beans. So the session beans are the only objects that need to be remotely accessed, and transaction aware.
With this architecture, you can still access your database with RMI/EJB, but what JDO does is saves the extra overhead involved with session beans going through RMI to call entity beans, particularly when they are typically on the same box, and in the same JVM. Since JDOs are also just plain java objects, it also makes it easier to program. No more remote, home, bean and primary classes and deployment descriptors, just a nice plain java object.
Floyd
|
|
|
Message #4186
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
I agree that JDO is very promising, especially when using the session-wrapping pattern.
I do think, though, there are situations where design aspects 3 and 4 are desirable. The case would be when the transaction occurs outside of the scope of a single method. This situation would arise when the developer wishes to allow the user to edit several pieces(from potentially disparate sections of the datastore graph) of data across multiple screens, and then either commit or rollback these changes as a whole.
Without remote invocation, it seems to me, the developer is forced to, if they decide to try to do this, to recreate the graph in the database, using value/data objects. This is very cumbersome.
I am still trying to take in the JDO specification, and understand if it will be possible to move transactions across JVMs and methods.
Any clarification on how JDO handles transactions is appreciated.
John Kelvie
|
|
|
Message #4323
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi, Floyd:
Thanks very much for your reply and sorry I did not make my point clear. What I tried to say is:
There are 2 application servers.
One is Oracle application server which hosts only database related EBs and Session beans. These beans get data from database directly through oracle JVM. No JDBC or RMI needed.
There is another application server which host all other none database related tasks. For this second application server, those EBs and session beans located in the Oracle application server are remote objects. A business logic bean in the second application server will have to talk remotely to an EB in the Oracle application server.
I think there are other database venders are making similiar systems.
This is just a idea. thank you and anyone tell me problems in this design.
|
|
|
Message #4324
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
The "database related EBs or Session beans" here are beans which access database directly. No wrapping in the Oracle application server. These beans could only remotely wrapped by ohter business login EJBs located at other application servers.
Yang
|
|
|
Message #4424
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Just an addition to Floyd's comment about the usefulness of Entity Beans for caching frequently read data. This supplement might be useful for any tyros who take on board Floyd's point without investigating it further.
The logic is impeccable: if the container holds your regularly used bean and you are only reading from it, then you cut down on database access. However, the implementation isn't quite so straightforward.
For instance, WebLogic users will know that you have to use the dbIsShared and isModified deployment settings (where appropriate) to prevent the default situation, in which the container reads from and writes to the database EVERY TIME a transaction touches the entity. This is even if you are reading a single property from a getX method. Other containers might do this a bit more cleverly, so your mileage may vary, as they say.
Also, you have to watch accessing an entitly multiple times for the data you need (calling lots of individual getX methods) as each call goes through all of the container glue. How many getX calls, I wonder, would you have to be doing to be slower than getting all the fields in one go using JDBC? (Another route to ameliorating this problem would be the use of bulk accessors - data objects - which I know you discuss elsewhere.)
Kind Regards,
Matt
|
|
|
Message #5602
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Floyd,
Is it possible to use, instead of the standard proxy, one which bypasses the RMI/IIOP, and directly calls the container stub of the EJB _if_ the EJB is in the same JVM as the caller?
I see no reason why such a "local proxy-stub" could not be implemented. It would still allow the container to intercept calls on the Entity bean (or session bean) and would allow transactions to be coordinated by the container, yet it would avoid RMI when local calls are made, which would boost performance for Entity beans that are accessed only via Session objects.
Regarding transactions for entity beans: is it desirable to keep transaction properties on entity beans? Perhaps, so that entity beans can explot the "requires new" attribute, for fine grained access?
What are peoples thoughts on this?
- Michael.
|
|
|
Message #6343
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Michael,
actually I believe (although I can't quote one off the top of my head) that some app server vendors actually do a 'conversion'/detection of an RMI call into a local call if it detects that it can satisfy the request by calling an EJB in the same JVM instance. This is no doubt one of the features that allow the different vendors to differentiate themselves in terms of performance.
Remember that EJB is a distributed object architecture so that you should not worry where the object is. By specifying a local call you are implying that you know what and where to run something better than the container (which may or may not be true). It's a little akin to trying to force a particular access path to a database table instead of allowing the DBMS optimiser to do it for you...Actually after that last comment maybe you are better off calling a local proxy :-)..Seriously the issue is one of theory, container implementation and practice..
Eddie
|
|
|
Message #7117
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi floyd,
Few points to add .
I find Toplinks an excellent Tool. It gives U so much flexibity in terms of querying the database . It is really a big pain otherwise like dynamically changing the query stmt during the run time , table joins ..etc. Practically find it very fast and efficient.
sudershan vellore
|
|
|
Message #7348
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi all,
THE FAULT OF EJB
1. Note that is would be rather unusual for reasons of performance to have one database connection for each object instance except than in rather simple examples. Often connections are pooled in order to make handling them fast, and here the code behaves as if connections came cheap :-).
2.Also note that we have no complex mapping of objects to tables involved here. In fact objects and rows are mapped 1:1
3.We also find no special code for object id's, smart pointers and the like - this is all handled by a simple primary key string.
(come from http://www.objectarchitects.de/ObjectArchitects/orpatterns/EJBPersistence/AcountEJB.htm)
4.The Data Model Doesn't Drive Your Class Diagram
(come from http://www.ambysoft.com/)
THE FAULT OF JDO
1.objects and tables are mapped 1:1 ( if you store object to
table)
2.if use JDO, Bussiness Objects have to stay in the same place with JDO objects
so , I think that JDO and EJB are not the complete solution for the store of objects. They can not auto fill the gap of mapping objects to tables.
|
|
|
Message #8894
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
And who was the "keeper" of the Persistence Service? None other than Roger Sessions!!!!
Bwahahahahaha!
|
|
|
Message #9771
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
This whole EJB and JDO topic seems tragic to me. Its a wolf ticket--the lot of it. Pick up Gemstone. Look at the way they do it. Its beautiful. Transparent persistence, collections apis that scale against concurrent updates. Transactions that may take up memory, but only from a pool of VMs running against shared memory, and even that can be distributed across a network. SSL from every point to every other point. You can even run a distributed transaction across multiple threads. You can't do anything that sophisticated with EJB, even with JDO. If you are serious about solving hard problems, why would you shackle yourself to these standards? What do they really buy you?
|
|
|
Message #9937
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Mark,
Using JDO with Gemstone would allow you to take advantage of many of Gemstones awesome features, all while maintaining portability and the ability to tell your boss that your code is standards based (with the usual reasons why that is good). :)
You could potentially develop your application on the J2EE and JDO reference implementations (upcoming) and then just deploy to Gemstone!
Floyd
|
|
|
Message #10006
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Well, the whole idea of EJBs is that you do NOT do anything that sophisticated, but do everything the KISS way (keep it small and simple or keep it simple and stupid, as you like :-) and let the container manage all that sophisticated stuff.
What I doubt is that this really works. Especially for smaller applications, normally the programmer (you) know better what to do.
However, with complex enterprise applications it is very often the case that you do not know exactly what the best cachign strategy is etc. and it was quite often proved that if you let a "container" do the work it will be faster in the end.
Just keep in mind that the people developing the container focus on this, they do nothing else than implementing the container.
And if you look at e.g. Orion AppServer (www.orionserver.com) or Inprise's AppServer (www.inprise.com) you'll see that they really know how to do their work. I doubt that with a sophisticated application you'll get the same performance by coding some things by hand compared to using the container. And the big advantage is: You have no such "sophisticated" things you mentioned: your code is easy to read and maintain, simply because it is "stupid".
I think adhering to the J2EE blueprints is enough: Don't use too many getter/setter methods, use property objects, don't implement _everything_ as an Entity Bean... and you'll have a nice time.
just my 2 cents
Messi
|
|
|
Message #10110
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi Richard,
I have already used JDO for small expmles. I think that JDO and EJB will compete in sense of customer choise only. i.e. a customer may wish to have future scalability for system (which EJB provide), or vice versa a cutomer just see that database will be used only by web server without middle tier. My point of view: JDO will compete with JDBC rather than with EJB, and it is a very good idea to use JDO instead ow raw JDBC when implementing EJB Entity Bean... JUST IMAGINE: distributed optimistic transactions by few lines of code -- distributed due to EJB/IIOP, optimistic due to JDO. In this case you should not remember about ejboad()/ejbSave().
Truly Yours,
Alexander Zynevich
|
|
|
Message #11153
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
AMEN! I fully agree.
Perhaps Floyd has a point with using JDO to access
objects in Gemstone, but I'm not sure if we'd lose
anything that way; if we do, I don't want it :-)
I'm perfectly happy with Gemstone the way it is today.
Frank
|
|
|
Message #11304
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects - current status?
It seems not much has been done on moving the spec through the approval process. The last update was over 7 months ago. I this really going to become a supported spec anytime soon? Is interest in the EJB 2.0 spec going to kill the JDO?
|
|
|
Message #11336
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects - current status?
JDO is having an impact on both the EJB 2.0 spec (debate involves dependent objects specified in the latest draft vs. JDO, not entity beans vs. JDO) and the JCA spec (as an alternative to the currently specified CCI).
Quick aside: Of the many advantages of JDO mentioned above, one that I didn't see is this: JDOs have the ability to specify a field as transient for the purposes of serialization (client access) but persistent for the purposes of data synchronization (server-side access). Nifty.
In any event, I strongly believe that we'll see JDO upgraded to a more prominent position in J2EE, and believe that in most cases one gains nothing by making use of entity beans instead of JDO -- particularly since standard practice seems to be to front entities/JDOs with a session facade, a pattern which provides the all security and transactional advantages to JDOs that entities offer. All that's lacking in the JDO area is a well-marketed implementation and a few vocal evangelists.
|
|
|
Message #11602
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi
Can you elaborate a little bit further onto why you would
have prefered not to develop your own persistence framework?
We are considering this alternative in my company and are looking for facts prior to the decision.
Regards
Echeyde
|
|
|
Message #13340
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
JDO has several caching and transaction options that were designed to be useful in EJB servers.
1. Optimistic transactions, in which no database locks are held until the user commits.
2. RetainValues after commit, cached instances retain the values they had during the transaction. The values will be refreshed on request (via API) or will be preserved (using Optimistic transaction) or will be automatically purged (if modified using Datastore transaction).
3. Multithreaded access to the same cache. This can be useful especially for read-only nontransactional accesses. This does need cooperation from the pooling mechanism in the server to reuse the same PersistenceManager for multiple nontransactional bean accesses.
4. GetObjectById which allows the user to get a transactional instance of a read-only instance from a nontransactional cache.
Craig
|
|
|
Message #13343
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects - current status
The current status of JDO is "implementation" of the draft 0.92. We have recently released the first milestone RI that will allow you to try out the code and APIs. There are two reference implementations planned: one with a native file storage (with remote access via socket protocol); and one to use SQL via jdbc.
We do not see interest in EJB 2.0 as competitive with JDO. Just the opposite. JDO was designed with EJB support as an objective, and will integrate with the transaction and security model of EJB.
JDO already has the required infrastructure to support Session Beans of all flavors (BMT, CMT, stateful, stateless), and Entity Beans using BMP.
Some JDO vendors (not publicly announced) will use JDO to implement CMP.
Craig
|
|
|
Message #13433
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects - current status
Hi,
I have a question regarding the JDO spec. I know I should have read the spec before asking this question, but bear with me if you don't mind.
I have a J2EE application that currently uses entity beans with BMP where the O/R mapping is done entirely through PL/SQL stored procedure calls rather than relational tables. My question is: does the JDO spec allow support for this type of O/R mapping, where what you're mapping to is not DB tables per se, but rather stored procs. And, If that support does not come out of the box, are there hooks where you can extend JDO to provide such a custom mapping.
If it doesn't, does that mean that all J2EE applications that currrently rely on stored procedures will not be able to leverage the JDO functionality.
Thanks,
Mike.
|
|
|
Message #15502
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Mark,
I love Gemstone. It's very close to my heart as a way of solving hard problems.
But, as an ODBMS, it still lacks a lot of crucial features that one has to write on one's own. (Like indicies over collections).
A standard doesn't give you any technical benefits - it gives you soft benefits -- a piece of paper that standardizes the training & skill sets requried for developers. Yah, it's not perfect, but there just aren't enough developers out there that can roll their own indices. :)
NOW, as for JDO as an alternative to Entity beans
- It's too transparent in its current form. More transparent that EJB 2.0 CMP.
- How does one manage bi-directional relationships, many to manys, and delete constraints?
- How does one maintain indices and other fast-lookup structures for fast retreival? ("Use JDBC" isn't an answer.)
I'd love a new spec to compete with JDBC and EJB 2 CMP, but I don't see it. We really should be learning from Apple's WebObjects EOF or TOPLink. I mentioned this briefly to Linda DeMichel after her JavaOne talk last year, but my impression was that she wasn't aware of such toolkits (though maybe I misunderstood). They're not standard, but we definitely can learn from them.
|
|
|
Message #16174
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
> - It's too transparent in its current form. More transparent than EJB 2.0 CMP.
JDO was designed to be more transparent than EJB, and to work in any tier from embedded to enterprise. Don't know about "too transparent".
> - How does one manage bi-directional relationships, many to manys, and delete constraints?
The direction of JDO is to support bidirectional relationships via a notation in the XML, with the same semantics as EJB CMP 2.0. Many to many is already supported by the JDO spec. Delete constraints are outside the domain of JDO. They are properly a datastore mapping issue that JDO vendors will provide as product features.
> - How does one maintain indices and other fast-lookup structures for fast retreival? ("Use JDBC" isn't an answer.)
The XML has a way to allow the "deployer" to add stuff like indices to fields in the persistence capable classes. The JDO spec has an example of this...
> We really should be learning from Apple's WebObjects EOF or TOPLink.
I agree. JDO had an engineer from TOPLink on the expert group, and currently has an engineer from Apple on the team.
Craig
|
|
|
Message #18889
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Regarding Apple's Enterprise Object Framework product. I've been a Nextstep and Openstep programmer and have done my share of EOF programming. Does Toplink delivery a control layer similar to EOF ie. EOEditingContext? That's where Apple made things easy to work with. No just the relational-object mapping via to-one,to-many relationships but seemlessly sychronising object and database state via EOEditingContext. I've not seen anything like EOEditingContext in the JavaSpace and I've worked on Java projects where such synchonisation had to be explicitly handled by the programmer adding to the complexity of the code.
Apple's Enterprise Object Framework pioneered relational-object mapping technology that worked. Optomistic locking out of the box.
Unfortunatley I transitioned into the J2EE space which kind seemed like going backwards aftering using WebObjects and EOF. WOF in particular is significantly more product a toolset to work with than JSP and Custom Tag development.
|
|
|
Message #18898
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Craig,
"...and to work in any tier from embedded to enterprise."
Perhaps we could just target one, make that work, before we take on all footprints. Java itself tried this before they gave up and split it off into Micro, Standard and Enterprise.
" Don't know about "too transparent". "
What I'm suggesting is that a "black box" approach will not work. Abstract the details from me, but give me access to those details so I can manipulate them where necessary. Similar to how EOF works with EOControl -> EOAccess -> EOAdaptor. In JDO this could mean JDOMain (object API) -> JDOSQL (sql-generation specific) -> JDBC.
The approach is that JDO can and should work with any persistence model, but a default implementation for SQL should be exposed since 90% of scenarios would leverage an object/relational mapping of some sort.
Robert,
Still waiting for WebObjects 5 to support EJB, so it's politically acceptable to use again :)
As for TopLink, yes it provides something similar to EOEditingContext, they call it a UnitOfWork. It does the same thing as EOF: it takes snapshots of the data, clones of the objects you manipulate, and a merge on a saveChanges(), generating the necessary SQL calls. All the common optimizations of EOF are there: faulting, uniquing, batch faulting, raw rows, qualifier-based query API, fetch specifications, etc. The terminology is different but the features are identical.. TOPLink came out of the Smalltalk world so it's not too far from the Objective-C point of view.
The major thing that EOF has as an advantage is its "generic property container", or EOKeyValueCoding and EORelationshipManipulation. TopLink doesn't provide such a mechanism, though it's not to hard to write one on your own.
|
|
|
Message #19486
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
One of the reason lot of people is wrapping entity beans in session beans is to simulate relationships. It's a waste of to make a session bean act as a wrapper to only one entity bean without processing the data. And this happens a lot when your're building an app with a web interface (like a e-store) if you want to stick with the popular model
"JSP-Session Bean-Entity Bean".
IMHO the problem with the perception of Entity Beans is that every one wanted to do with them everything we did before with SQL and the EJB 1.1 didn't give you that in the specs.
And the performance problem with BMP makes them nearly useless if you're accessing lots of object. And the overhead of the RMI calls can serious hamper your performance.
But not everything is black in the entity bean world. As some have pointed out there are containers that don't use RMI calls if the bean is local (they detect it automagically). Some container gives you vendor-specific mechanism to persist a 1-n relationship, etc. In other words, if you choose the rigth tools programming using CMP Entity beans is really a pleasure.
BTW, I see JDO as the perfect partner for EJB. You can use JDO to persist EJB. You can use them when a lightweight solution is good enough. You can use JDO to create "views" of the data persisted with EJB (Oracle uses View Objects and Data Objects in their framework).
|
|
|
Message #22703
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
In the techmetrix article (http://www.techmetrix.com/trendmarkers/tmk0201/tmk0201-3.php3), it says:
"...the developer does not have to directly manipulate native interfaces for access to different resource managers..."
Does this mean the client-side developer does not have to have any knowledge of the SQL being performed by the JDO implemented classes ?
Ian Spence
|
|
|
Message #22880
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Correct. In fact, a JDO runtime could use SQL for RDBMSs, OQL for OODBMSs, or anything else that it can work with.
That's what 'transparent persistence' is all about.
|
|
|
Message #23000
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi all,
I just read the topic, I am late, but I would like to join the discussion anyway.
I disagree on your 3th point and, as a consequence, partially on the 4th one. Other contributions have given reasons that I agree with so I will not repeat those again.
According to http://developer.java.sun.com/developer/restricted/patterns/AggregateEntity.html:
"Entity beans are not intended to represent every persistent object in the object model. Entity beans are better suited for coarse-grained persistent business objects. "
The fault is not in the design of EJB specs, but in the way the developer community used Entity beans. The key question is not if an object must have a persistent state (that can be persisted with any available technology, JDO comprised). The question is if a persistent object must be distributed and transactional. I agree that is not common have this requirement, but in some Enterprise architectures (and than applications) it can be. I think the biggest mistake is to look at any web application as an enterprise application by definition! It is simply not true!
To summarize, my opinion is that JDO and Entity Beans are not in competition, because they must be used in different context.
At least with EJB 1.1. With EJB 2.0 and Local Interfaces it might be another story and perhaps... another thread :-)
Cheers
Stefano
|
|
|
Message #23527
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects - current status
My company Object Design is represented on the JDO expert committee. Craig Russell mentions above that "Some JDO vendors will use JDO to implement CMP." I imagine we are one of several Craig has in mind.
We market a transactional cache manager for EJB application servers named "Javlin". Javlin supports CMP and BMP as the interface(s) the EJB application can use to cache data locally. Inside Javlin under transaction management and routing etc. is a proprietary API somewhat reminiscent of JDO for transparent object Storage. We plan to migrate Javlin forward to JDO as JDO persistence implementations become generally available.
The API JDO will replace is not central to the value in Javlin which sells to TP sites wanting more scalable access to backend data (through caching) and the opportunity to trade one persistence manager for many potentially broadens our market substantially.
Since our JDO plans for Javlin aren't secret, no harm using it to support Craig's contention re JDO and EJB 2.0 being complementary technologies.
|
|
|
Message #23538
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects - current status
Henry,
Having used ObjectStore in the past, this is good news from Object Design.
Does this mean that JDO will fully replace the ObjectStore Java Interface (OSJI) or will JDO simply be an adapter ?
Although you mentioned that Javlin will be migrated forward to JDO over time, can you give us an idea of when this will generally be available ?
Cheers
|
|
|
Message #23918
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Michael,
An excellent insight that I think many people miss. An
Entity Bean != Database Row. It is easy to think of it
as such, but even the EJB Best Practices from Sun warn
againt it.
An Entity Bean is the *logical* representation of a noun
or thing expressed in the problem domain.
Unfortunately there is a tendancy to immediately associate
an Entity Bean with a database.
*Intent* != *Mechanism*.
Cheers,
Noel.
|
|
|
Message #23977
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
The problem with EB(esp. #2, #3 and #4) is that it is responsible manipulating my persistent store and from a RDBMS world perspective until my DB vendor(I guess Oracle is finally starting to work on it) provides strong tightly integrated support for these mechanisms I'm just not confident that the middleware vendors will be up to the mark both in terms of performance and data integrity.
|
|
|
Message #25927
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
It is not Necessary that U Should Use Entity Beans . If At all U are using entity beans , Optimize it through control of ejbLoad() and ejbStore()...... using a dirty flag ..... Java Data Object is good and more flexible ...... Each Instance of EJB calls corresponding Instance of Java Data Objects....In this way it is better to Persist Objects using JDO....Never Ever use Entity Beans just for listing purpose which actually reduces Performance...
|
|
|
Message #25986
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
(I actually would like to ask a question about JDO Query. Sorry if I break the thread of questions, but since this is the largest JDO discussion group I found, I think someone out there might have interests in knowing this too.)
The way I understand it is that whenever we want to do a query, even a simple one that retrieve data in one cell, we'd have to do a getExtents() on the persistence manager first, which is essentially a "select * from table" for RDBMS. But this would mean retriving every objects into memory. Isn't that inefficient? (e.g., if there are 100000 objects, while all I want is just one.)
|
|
|
Message #26111
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Two replies to your question:
1. The PersistenceManager.getExtent(...) returns an Extent instance that represents all of the instances in the data store, but does not necessarily retrieve any of them. So in that sense, it is not really the same as select * from table. An optimized JDO implementation will not instantiate any instances of the class unless you actually get an Iterator from the Extent and start iterating. Normally, the Extent is simply a marker that tells the Query how to optimize itself. Even if you get an Iterator, the JDO implementation can still lazily retrieve instances from the data store. That's why an Extent is not a Collection which has a size() method, but it does have an Iterator that simply gives you the next instance.
2. The other way to retrieve an instance, without running a Query, is to perform PersistenceManager.getObjectById(...). This assumes that you know the JDO object identity, which you get by taking the object you got earlier from PersistenceManager.getObjectId(...) or by construction (see PersistenceManager.getObjectIdClass(...).
|
|
|
Message #26211
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Floyd as you know your point #3 is not valid any more, because EJB2.0 gives you the option of local interfaces too. But I still don't believe how most of us just over look the designing issues related to Entity beans. Entity bean defies all the lesson of good OO designing. Since when we have to look into RDBMS to design our domain objects. Our design should be driven by business needs rather than the database (OO 101). I think O/R mapping tools have done a really good job to achieve this goal, e.g. Toplink. Second your domain object should be portable, it is so ironic (write once run anywhere),why you always depend on EJB app server to execute your domain object. It should be callable from non-managed environments too. IMHO JDO done a very good job regarding the fact that you can call your domain objects from non-managed environments too. We wasted too much time on entity bean and all the baggage it comes with, I wish we all should paid attention to Roger Session two years ago.
|
|
|
Message #26354
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Rashid,
I can honestly say that I agree, 100 PERCENT, with everything that you said. Here here!
Very well stated.
-- Rick
|
|
|
Message #26577
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Rashid,
I also agree 100% with what you have said.
Craig
|
|
|
Message #26605
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO vs. Entity Beans
My questions are
A. What are the advantages of each technology (entity-bean vs JDO) ???
B. Is there any other mature technology to perform this task except entity-bean and jdo ????
C. What is the best choice at this moment to represent complex object that involve more that one table row and more that one database ?????
Thanks guys!!
|
|
|
Message #26622
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO vs. Entity Beans
Eric,
Check into TopLink and CocoBase.
They have really excellent persistence frameworks which can be implemented with or without the usage of EJB.
Regards,
Rick
|
|
|
Message #26632
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO vs. Entity Beans
Eric,
I work for Object Design, makers of ObjectStore and Javlin. You might want to take a look at Javlin, which will let you manage complex relationships between objects persistently. Javlin avoids the entire relational join issue with highly interconnected object graphs. We also provide a layer of transactional caching over our persistence to keep frequently used objects available in-memory. These caches can be also kept synchronized against any data source (relational, or otherwise).
Good Luck!
Bill Dettelback
Systems Architect
Object Design
|
|
|
Message #26727
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO vs. Entity Beans
I would also look at ODMG 3.0 (www.odmg.org). In particular, Poet's database product, formerly "Object Server Suite", now "FastObjects", is a joy to work with.
They will also have a JDO implementation coming soon, which I anticipate to be as good as their ODMG-compliant product. Any limitations, I imagine, would be the result of the specification and not Poet's implementation of it.
By the way, I don't work for Poet nor am I a stockholder.
There is an impedance between EJB transactions and ODMG transactions right now, but that's one of the things that JDO attempts to solve.
--Matthew
|
|
|
Message #26764
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
I guess the best solution in future will be stateless session bean + JDO.
We get Tx and distributed benifits from stateless session bean, and get persistence from JDO.
Entity beans are performance poor because they are unnecessarily distributed and Tx oriented objects.
But when will JDO integrate with EJB spec? EJB 2 still uses entity bean, not JDO.
Actually comparing JDO and entity beans is just like comparing Beenthoven and Mozart. who knows which one is better?
minjiang
|
|
|
Message #26793
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Thanks Craig,
How do we incorporate an Oracle sequence number to the persistent capable object then? That is, since JDO automatically insert objects to the database via makePersistent(), and assume that we created a seqence called IDSequence in Oracle, we would then have no way to tell makePersistent() to please also insert the "IDSequence.NEXTVAL" for us. Are there any workarounds?
|
|
|
Message #26938
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi all
I checked the list of vendors supporting JDO.
Does this short list imply that Oracle, IBM and Informix are not supporting JDO on top of their databases ?
Jan Nilsson
|
|
|
Message #27432
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
I have one question to ask.
After read the specification and test some jdo implement, I still do not know how to update a persistnet instance that changed outside an active transaction.
For example, if I change a employee instance in JSP and I what to update it to datastore, how should i do?
Thank you.
|
|
|
Message #27841
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PrismTech roadshow with Craig Russell
Is anyone going to the PrismTech roadshow with Craig Russell speaking? (I'm going to the London one.)
http://www.prismtechnologies.com/English/News/events/jdo/index.html
Any views on why an integration vendor, rather than a more obvious persistence specialist, should be hosting it? Where are WebGain/TopLink, cocobase, etc, and Oracle, Sybase & Versant?
Jeremy.
(Just by way of keeping the forum going...:)
|
|
|
Message #28038
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Rashid,
I do not understand why should I keep O/R mapping in mind while designing EJB 2.0?
----spec----
The container managed persistence architecture thus provides not only a layer of data independence between the client view of a bean as an entity object and the Bean Provider’s internal view of the bean in terms of the entity
bean instance, but also between the entity bean instance and its persistent representation......
It is the responsibility of the Deployer to map the abstract persistence schema of a set of interrelated
entity bean classes and into the physical schema used by the underlying data store (e.g., into a relational
schema) by using the Container Provider’s tools.....
The Container Provider’s tools can, for example,
generate classes that use JDBC or SQLJ to access the entity state in a relational database; classes that
implement access to a non-relational data source, such as an IMS database; or classes that implement
function calls to existing enterprise applications. These tools are typically specific to each data source.
------------end-----------------
Sure that this "Container Provider’s tool" is specific for evry App Ser and Data Store Engine.
Peter
|
|
|
Message #28282
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi Jan,
With regard to product announcements by IBM, and other large companies, often there are strict rules about vaporware announcements. So even if IBM were intending to support JDO you would not necessarily hear about it from them until they had product almost ready to ship.
And please remember that JDO is not yet a standard (although we are getting very close).
Craig
|
|
|
Message #28615
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
I am curious. Most of the criticism I'm reading here of Entity Beans has to do with performance, or the pain of writing them.
If there was a J2EE implementation that provided high-performance container-managed Entity Beans, and development tools that made using them correctly and creating them easy, would that solve the criticisms?
I'm asking this in a general sense, not to get product recommendations. So, "could a great implementation fix Entity Beans?", not "what is a great implementation of Entity Beans?"
At Persistence, we like to think we have a great implementation, but I'd be really interested in knowing of there are new architectures we should support, for design or architectural reasons (rather than just complaints about Entity Bean performance, which we see as a non-issue, because ours are very, very fast).
Thanks!
Michael Alderete
PowerTier Product Manager
Persistence Software
|
|
|
Message #28740
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
I'm starting to play with the currently available JDO implementations.
One criticism I have is with respect to accessing field names. Because the field names are the same as the (most likely private) instance variable names in my class, I must now code all my variables without any prefixes or suffixes.
Not a show stopper by any means but having spent many years using a JavaBeans paradigm with getters and setters, I must now expose the actual field names.
Honestly, I can't think of a better solution but, it is a bit annoying.
|
|
|
Message #28780
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
The enhancer of Rexip JDO will generate the get/set functions which should take care of the field name issues.
Visit www.rexip.com to get a download. Send me a note if you have any question.
Cheers,
- Niles
niles@tccybersoft.com
www.rexip.com
|
|
|
Message #28856
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
It's not really the generation of getters and setters I'm worried about, it's the fact that now in my quueries, I must know that internally the variable name is "x" or "_x", etc. If you look at CastorJDO, it can use the JavaBeans paradigm for variable naming.
|
|
|
Message #28897
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO for accessing files from a file system?
I have a question about JDO.
Until now you cannot access flat files from your EJBs
(io access). EJB spec. does not allow this because of
the transaction behaviour.
Can I use JDO for accessing flat files from my EJBs?
If JDO supports transaction, then it should be possible
to create, delete flat files from a file system
within a transaction?
Will be a flat files implementation of JDO available?
Thanks a lot!
--
---------------------------------------------------
Blasius Lofi Dewanto
---------------------------------------------------
OpenUSS - Open University Support System
http://openuss.sourceforge.net
---------------------------------------------------
|
|
|
Message #29076
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Three patterns here for the JSP (or control servlet):
A. If the JSP received a managed PC object (which it might if the business service accessing JDO was local to the servlet/JSP level), then the business service (application layer that wraps use of JDO) can open an optimistic transaction when the object was returned to the JSP. The JSP would store the reference to the business service and the persistent instances that it will present in the session. When the next HTTP request comes indicating a change to the data (assuming that the change is initiated by the HTML user), the JSP (or control servlet) looks up the service and the object in the session, applies the change, and requests that the business service commit the transaction.
B. If the JSP received an unmanaged PC object (as would happen if the business service was remote and objects were passed by serialization -- as happens with EJBs), then when the HTTP change request comes in, the JSP (or control servlet) must look up the service in the session, and then make a "change this for me" type of request. The remote service will need to know three things to satisfy this request: what is to be changed (this might be indicated by a method name: e.g. updateAddress), what the new value is that needs to be set, and what persistent object to apply the change to. The client of the remote service (the JSP or control servlet in this case) can indicate the persistent object by supplying key fields or passing an object ID -- the business service must arrange to send the object ID down during serialization. The EJB itself (certainly true for entity beans) may already know what object is to be changed, so the client may not need to pass key fields or object ID.
C. (A variation on B) If the business service has taken care to store away a serializable reference to the object ID, then the control servlet can apply the change requested to the unmanaged PC instance, and send it to the business service, which then finds the matching persistent object and updates it with an application supplied MyPCClass.update(MyPCClass) type of method. The update tells "this" to adopt all the "relevant" values of the passed object. Care must be taken with references to other PC objects within the passed object, since they will also refer to unmanaged instances, and the application may very well want the references to be to existing persistent instances.
I have a a talk online whose demo code shows approach C -- probably not perfect by any means -- to wrap the business service logic, so that the business service can be deployed either local to the servlet or remote in a session bean. Using the patterns above, one can come up with numerous variations. The notion of having redeployable business logic makes sense when you consider the current interest in "right sizing" web applications.
David Ezzio
Yankee Software
|
|
|
Message #29078
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PrismTech roadshow with Craig Russell
Jeremy,
I'm going to the PrismTech roadshow in Burlington.
I'm quite happy to speculate on Toplink, CocoBase, and Castor. First, JDO is not focused solely on O/R mapping, which each of these products are. Second, the architects of each of the three products feel (in my speculative opinion) that the design choices that they have made are superior to the design choices of JDO. This may be because of the difference in focus, and this may be because the other three have had more time than JDO to refine what they are doing. Or perhaps it is a Not Invented Here syndrome. Finally, in the case of the two proprietary products, I think there is a problem of pricing and position. JDO will both enlarge the market for the use of a persistence layer and bring in a lot more competitors for that market. Both Toplink and CocoBase are successful and they are reacting like a deer in the headlights to JDO. I believe that they need to realize (before it is too late) that they have the opportunity to add significant value added features to JDO before anyone else. Instead, they appear to be hoping that JDO goes away. But remember, this is all one man's speculation. Perhaps those more knowledgeable will jump in.
While as users we certainly appreciate standards and ubiquity, we must remember as engineers (and managers) that the process of introducing ubiquitous standards is one of creative destruction.
David
|
|
|
Message #29103
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
1) Is optimistic concurrency (!= optimistic locking) with timestamps/versions/whatever possible in JDO?
2) What if there's need to run a query that cannot expressed using JDO QL? Can JDO support custom queries in direct SQL or stored procs?
3) Suppose, there’s an application that reads data from department table department table (id, name) using three (3) types of queries:
selectAllDeparments()
selectByPK (id)
selectByName(name)
How would JDO cache be used in the above cases?
Thanks in advance
|
|
|
Message #29107
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
In the implementations that I have looked at (just Kodo to any extent so far), JDO optimistic transactions are supported using a concurrency field. I didn't know there was also optimistic locking to wonder about. Perhaps you could illuminate what the difference is.
The JDO Query interface requires support for the JDO Query Language as defined by the spec. Implementations are free to support other query languages, and the Query interface has the hooks to support constructing queries with these additional languages. In the case of an O/R JDO implementation, it would make great sense as a value added feature for the implementation vendor to support SQL calls, stored procedure calls, etc. Given that everyone is just trying to implement to a public draft of the spec right now, I wouldn't expect to see this value added feature until at least version 1.1 of an implementation.
The spec talks only about the Persistence Manager cache. Any caching or cache synchronization that goes on at a lower level is entirely implementation dependent. For a PM cache, it is 1) dedicated to one PM session, and 2) controlled by the transactional options (RetainValues, NontransactionalRead, NonTransactionalWrite, and Optimistic), and 3) controlled by whether the application observes or does not observe transactional boundaries (whether it starts and completes transactions, or just runs non-transactionally), and 4) controlled by the application's use of refresh and evict methods. Caching issues can be, therefore, as you can see from all of these influences that I have cited, potentially complex.
However, there are I think three patterns that will be commonly used. (All three use !NTW.)
A) Observe transactional boundaries, !RV, !NTR, and !Optimistic: This is appropriate when there is no user think time, and the highest throughput consistent with transactional processing is desired. The only downside is that depending on the relational database, the isolation level, and the JDO implementation, it is possible (just as it is with any SQL application) to lose overlapping updates (two transactions that read the same state, update it independently, and commit -- though both transactions are persisted to the database, the second one overwrites the first and is based on a read that occurred before the first transaction is applied).
B) Observe transactional boundaries, !RV, !NTR, and Optimistic: This is appropriate for either of two cases. One there is user think time in the transaction, or two, the application wants to catch overlapping updates (see above). It takes a little more database resources overall, but does not keep a datastore transaction open while the user is thinking.
C) Don't observer transactional boundaries, !RV, NTR, and Optimistic: This is a read only PM session, where the design tradeoff is to accept some measure of risk that the cache will be out of date, in return for the fastest possible access to the data. The risk can be reduced but not eliminated by a variety of application heuristics, among which are determining which instances are known to be out of date and then either refreshing or evicting them. Note however that if the application cannot accept the risk of out of date data and therefore desires to refresh every persistent instance that it touches, this pattern would become more inefficient than B.
So, in the case of A and B, the cache is a transaction bound cache that is cleared at the end of every transaction. What is the value of that? The clear case that I can see is when there is a thicket of interrelationships in the object graph, and if this graph is navigated every which way by the business logic of the transaction, then clearly it is efficient to load an object just once. Beyond that, I don't think the cache gains you much, but it certainly doesn't cost you much either.
I haven't been able to figure out any good use for NontransactionalWrite, and while I can see various ways to mix and match the three patterns above, I don't see any other transactional patterns that appear particularly useful.
David Ezzio
Yankee Software
|
|
|
Message #29112
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
I guess it one uses RetainValues it's possible to keep instances in cache beyond the scope of transaction.
Is it possible to force JDO to run query against cache only, without hitting DB?
Thanks in advance
|
|
|
Message #29166
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDO for accessing files from a file system?
Hi,
I don't know of any plans for a JDO implementation that would use flat files of the user's design (JDO RI, available in preview form today supports flat files of JDO RI's design). But the specification does not disallow it.
What you would do is to define a mapping from Java to the flat file, define a PersistenceManagerFactory that would describe the file, and implement a Connector that adhered to the Connector Architecture (JSR-19, part of EJB 2.0) to give you transactional access to the file. You would have to write the concurrency controls for the file system.
Regards,
Craig
|
|
|
Message #29167
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi,
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).
Regards,
Craig
|
|
|
Message #29169
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi,
1) Is optimistic concurrency (!= optimistic locking) with timestamps/versions/whatever possible in JDO?
JDO does not define the implementation of optimistic concurrency, just what happens when optimistic concurrency assumptions fail. That is, the implementation determines what constitutes an optimistic concurrency check. Some implementations might use a timestamp/version scheme. Others might use a concurrency group scheme. All are treated by JDO as optimistic concurrency.
2) What if there's need to run a query that cannot expressed using JDO QL? Can JDO support custom queries in direct SQL or stored procs?
There are a few ways that this can be addressed. One way is to ask your JDO implementation (via a non-standard interface) to run a SQL query for you, using your transaction's JDBC Connection, or alternatively, to give you a Connection bound to your transaction. This cannot be JDO standard, because of the reliance on JDBC. Another way is to map your SQL query to a Java class directly. For example, you might define a Java class to contain one field for each column of a custom query with one result row (perhaps a stored procedure), and define the key fields of the class to be the parameters of the query. Performing a getObjectById passes the parameters, and accessing any field value executes the query. You would get the results by accessing the fields of the JDO object. If the results had many rows, you could instead map the query to a JDO query that took parameters.
3) Suppose, there's an application that reads data from department table department table (id, name) using three (3) types of queries:
selectAllDeparments()
Query q = pm.newQuery (pm.getExtent(Department.class));
Collection depts = q.execute();
selectByPK (id)
Query q = pm.newQuery (pm.getExtent(Department.class), "depid == id");
Collection depts = q.execute(id);
selectByName(name)
Query q = pm.newQuery (pm.getExtent(Department.class), "depname == name");
Collection depts = q.execute(name);
Regards,
Craig
|
|
|
Message #29183
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Craig Russell wrote:
"Another way is to map your SQL query to a Java class directly. For example, you might define a Java class to contain one field for each column of a custom query with one result row (perhaps a stored procedure), and define the key fields of the class to be the parameters of the query. Performing a getObjectById passes the parameters, and accessing any field value executes the query. You would get the results by accessing the fields of the JDO object. If the results had many rows, you could instead map the query to a JDO query that took parameters."
This is going to be a matter of considerable interest, but unfortunately for me, I'm not sure if I lost the train at the beginning, the middle, or the end. My questions: What does the Java class (I'm assuming it's PC) get mapped to? A view? How does the getObjectById pass parameters to the query? How exactly does the query get executed?
|
|
|
Message #29828
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Craig,
Is it necessary to pass an extent or collection to a query? Or will a query where neither is specified grab the default extent(all instances of a class in the database)?
Also, with respect to the PersistenceManager, why is the caching mechanism associated at this level? If a JVM has multiple PMs, then maintaining a synchronized state between their caches would seem to be much more difficult than if the caching were done at a higher level(PMFactory perhaps). Also, seemingly only a subset of the entire set of objects being cached within the VM will be available using the PM caching mechanism. Do you perceive these as problems as well? How can this be avoided, or what am I not understanding here?
John Kelvie
|
|
|
Message #30204
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PrismTech roadshow with Craig Russell
This is in response to David's JDO speculation...
> I'm quite happy to speculate on Toplink, CocoBase, and
> Castor. First, JDO is not focused solely on O/R mapping,
> which each of these products are. Second, the architects
> of each of the three products feel (in my speculative
> opinion) that the design choices that they have made are
> superior to the design choices of JDO.
Actually the issue isn't that JDO is not focused on O/R,it's that it interferes with it, and actually is counter to many of the requirements of common O/R systems. Especially those with Enterprise requirements, such as instance copies, non-model intrusions, instance reuse, multiple copy reconciliation - the list is almost endless.
The problem is that Craig and the whole JDO spec body at this point has completely refused to accept feedback from the O/R vendors. This has caused sun to unwittingly create a spec that is completely inappropriate for O/R mapping requirements. Considering that Sun created that disaster of an O/R product JavaBlend - it shouldn't be suprising however...
It's not just that O/R vendors feel that their design choices are better - they KNOW they are. From years of experience, from years of R&D and implemented and in production software systems based on their products.
By contrast, it is my understanding that the folks who made JDO haven't built an enterprise O/R product. And from the current spec, while JDO seems fine for many ODBMS systems, the folks who designed it seem clueless as to the requirements of Enterprise O/R mapping...
> This may be because of the difference in focus, and this
> may be because the other three have had more time than
> JDO to refine what they are doing. Or perhaps it is a Not
> Invented Here syndrome.
At least for THOUGHT Inc. the first 2 are true, but the last one is not. CocoBase supports Java, Swing, JDBC, JSP, Servlets, EJB (BMP & CMP), etc. We're probably the most standards compliant solution on the market. We gave feedback to the ODMG folks years ago as to what was wrong with the ODMG spec that JDO was based on, and tried to give feedback to Craig and the other JDO folks. Instead of having an open mind and hearing our feedback, they rudely refuse to listen. We still hope that at some point JDO improves to a point where we could implement it, but at this point it would screw our product and our customers so we refuse to implement it. I personally feel sorry for the O/R customers who try to implement with JDO - it is bound to screw them in its current state just as ODMG implementations have typically done to customers. There's a reason that JavaBlend was killed at Sun, and coincidentally it was also ODMG based - a very similar design to the JDO system... I personally believe that it failed in the market because of it's ODMG architecture. We found that the design elements of ODMG stink for relational databases in the enterprise - and is barely useful for prototyping.
> Finally, in the case of the two proprietary products, I
> think there is a problem of pricing and position.
Pricing for CocoBase is per developer, and it includes an incredible amount of product integration, code generation, portable support for CMP, etc. If you think this doesn't provide value, then perhaps you haven't used our products.. On average for EJB customers for example customers can save millions on building their projects by using CocoBase. You could get a free JDO tool, but then the old addage of you get what you pay for comes to mind...
> JDO will both enlarge the market for the use of a
> persistence layer and bring in a lot more competitors
> for that market.
This is a bad assumption. There were actually more app server vendors before EJB, than there are now. The opposite happens in reality when standards are usually implemented. We personally don't mind, because we have a mature product, and customers worldwide. We're also a market leader in our space - and market leaders rarely suffer, and in fact usually thrive with the addition of a spec. Lets contrast the EJB space, and remember how quickly App Server vendors adopted EJB. We were similarly eager to adopt an O/R standard - the problem is that the current JDO spec isn't one, so we can't adopt it...
As for new vendors, there's a lot more to building a successful company and product that will be around for 5-15 years than just a specification. CocoBase has been commercially shipping for almost 5 years, and the reason our product is still shipping, when many of the dozen or so competitors have died or consistently lost market share is because we make products that customers want and need. It's because we build a system that usually runs faster than hand coded jdbc (unlike JDO), and that is non intrusive into the object model (unlike JDO), that works equally well standalone or within a distributed environment (unlike JDO), that is fully extensible (unlike JDO), that includes tool and product integrations (unlike JDO), that includes many runtime extension facilities (unlike JDO), and on and on...
Also JDO doesn't define O/R mapping, so the portability isn't likely to increase just because O/R vendors use it. We would have to reshape JDO and make it more proprietary than our current system in order to use it - which would in fact be bad for customers.
As it stands today the CocoBase APIs are very similar to JDO (if you visit our forum.thoughtinc.com site we actually even show code examples on some postings related to JDO). We just don't have the object model intrusions and stupid limitations currently required by JDO. But we do have full transparent persistence and very little coding required. And our Transparent Persistence facilities were built for distributed environments - the JDO spec doesn't even know what that means...
For CocoBase Customers implementation of the JDO specification to be non-intrusive is a non issue. This is because we already provide them with transparent persistence in a way that is less invasive and more portable than what JDO can currently provide...
> Both Toplink and CocoBase are successful and they are
> reacting like a deer in the headlights to JDO.
Actually like spectators in a garbage dump would a better analogy. I'm not stepping in that crap, I'll never get the stink off of my shoes...
Did you know that neither the CocoBase or Toplink designers were consulted on the JDO spec, and that it was designed entirely by ODBMS vendors/designers? No offense, but that's pretty arrogant to not involve the two market leaders in a spec that they are then 'told forcefully' to implement. And by someone that I personally found to be personality and diplomatically challenged... If THOUGHT Inc. had been consulted, or even treated nicely when we gave our feedback on JDO I would be reacting differently. But at this point the JDO folks don't want to fix their spec. They've never contacted us to this day to ask for our feedback, but they've made several nasty postings and customer calls that have made me believe that all civility has left that group entirely... My experience of Craig is that he's not competent to lead the spec. He may be a fine ODBMS engineer, but he's an awful diplomat.
> I believe that they need to realize (before it is too
> late) that they have the opportunity to add significant
> value added features to JDO before anyone else.
Well while in theory this is true, in reality if we add the required changes to JDO, we would actually have to implement our current products and ignore the spec. It isn't possible for us to implement all of our features in the current JDO spec, so that argument isn't valid at least for CocoBase. Perhaps Toplink 'could' shoehorn their product into JDO, but they would probably lose a few features as well.
> Instead, they appear to be hoping that JDO goes away. But
> remember, this is all one man's speculation. Perhaps
> those more knowledgeable will jump in.
Actually I'm hoping Craig replaced and that someone who isn't so arrogant and ignorant of O/R issues is assigned to lead the spec. I don't have a problem with implementing an O/R spec, but one has to be written first. The JDO spec is an ODBMS spec, not an O/R spec, but the folks who wrote it don't seem to have enough knowledge of O/R to actually realize that yet... They still think they have an O/R spec - when in reality they don't.
> While as users we certainly appreciate standards and
> ubiquity, we must remember as engineers (and managers)
> that the process of introducing ubiquitous standards is
> one of creative destruction.
Absolutely - we're just waiting until some creativity enters the JDO spec - currently it's all destruction...
Look please understand we don't have a problem implementing an O/R spec. After all we wouldn't have implemented our portable CMP solution, or our Session Bean Persistence technology if we didn't believe that it was important to produce non-invasive transparent persistence. But the JDO folks need to get a clue that being jerks and demanding that we implement a half baked and fraught with perils spec without listening to our concerns or input won't fly with me. We've spent years building a product and a market and are much closer to customer requirements than they are. When they realize this and allow us to help define a real specification instead of pronouncing standards from a stained ivory tower - then we'll probably be able to implement a spec that not only we, but that all O/R vendors embrace. Instead of JDO, which only O/R amateurs or some real O/R engineer who holds his nose would implement...
Just my $.02
A CTO very disappointed by the actions of the current JDO
specification group...
Ward Mullins
THOUGHT Inc.
|
|
|
Message #30273
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PrismTech roadshow with Craig Russell
Uhmm...Ward, no offense here, but I've looked at the specification very closely, and well it may not be perfect, it is a step in the right direction.
I would find your argument much more compelling were you to stay away from words and phrases like "stupid","barely useful for prototyping","not an o/r spec",etc. I find these assertions based on my analysis of the spec. very difficult to swallow, and they detract from other points you might be trying to make about JDO(such as problems it may have with enterprise scalability, which it seems to me it may very well have).
If Craig is such an arrogant guy, then I do indeed feel sorry for you. It is a shame for sun to do a specification without consulting you, toplink, and other players in this space.
But from another perspective, I have recently done some serious investigation into O/R tools. I installed the Toplink product, found it to be very well designed and implemented, and contacted a salesperson about purchasing. The price they told me was 5000 per developer using the gui mapping tool, 2000 per developer using the jar files involved, and 7000 per cpu(or maybe it was server. I can't remember). This is a LOT of money for this sort of tool. We pay less for our J2EE server, and I imagine at some point this sort of utility will be merely another part of these implementations. So we moved on and looked at Cocobase.
Now, Cocobase(a product which I have generally heard good things about), was a different problem. The pricing model was on the website, and it seemed like something that we could work with(4000 per developer, no per cpu cost). However, when a salesperson called me, he seemed like an intelligent fellow, and we were having a nice conversation, until I asked him if Cocobase was plan on the implementing the Jdo specification. At that point he went off on a rant very similar to the one that Ward has posted below. I thought this was both unprofessional and uninformed/willfully ignorant. The upshot of it all was that cocobase would most certainly NOT be implementing the spec.
No matter how bad the spec may be(and I won't even touch on this question, except to say it is certainly not as bad as it is being painted here), it is merely a spec: all it asks is that a vendor implement the interfaces from it. Though obviously this is a substantial task, I am sure if cocobase desired they could wrap their code to make it conform.
At the end of the day, one of the things I enjoy most about developing in Java is the degree of vendor independence it provides. My company develops enterprise software packages, and this means we have to be able to work in a variety of environments and with a variety of vendors. Though every implementation of the Jdo specification will surely mean a different approach to the actual mapping of tables and classes(though I imagine many will be using xml for this feature, as with cmp under ejb) the actual code that I and my fellow developers write, will, in theory, be able to remain the same no matter what tool we choose. I think this is a great thing, especially in a relatively immature space such as this one. I've seen this work for ejbs and application servers, and I believe it can work here. If cocobase and toplink don't want to get on board, for whatever reason(and please don't tell me it's because the spec is so horrible. I'm not an idiot, I'm a potential customer, and I am sure that there will be jdo implementations that more than meet our needs), they will be cutting off their nose to spite their face. Checking the jdo site, there are already several vendors lined up to implement, and some have products that are in beta. And I bet none of them is going to quote me a price anything like what toplink did.
Thats my opinion. Ward, I invite you to shed light on any ignorance I may have. But please be specific, and please avoid invective.
John
|
|
|
Message #30494
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
THOUGHT versus JDO
Ward Mullins wrote:
"The problem is that Craig and the whole JDO spec body at
this point has completely refused to accept feedback
from the O/R vendors. [...] [I]t is my understanding that the folks who made JDO haven't built an enterprise O/R product. And from the current spec, while JDO seems fine for many ODBMS systems, the folks who designed it seem clueless
as to the requirements of Enterprise O/R mapping."
Ward, the fault here lies at least partially with THOUGHT, Inc., which as a company does not appear to have taken advantage of an open process to influence the evolution of the JDO specification. Much smaller companies than THOUGHT have influenced the spec, why not you? You don't have to argue that your influence would have been beneficial (we'll grant that), and you don't have to argue that you would not have gotten everything you would have wanted in an O/R mapping spec, we all know that JDO has a broader reach than O/R mapping. But why not make the spec better for O/R mapping vendors to implement? That is something that THOUGHT Inc. could have done, and apparently decided not to. Why not?
|
|
|
Message #31282
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
David Ezzio wrote:
"This is going to be a matter of considerable interest, but unfortunately for me, I'm not sure if I lost the train at the beginning, the middle, or the end. My questions: What does the Java class (I'm assuming it's PC) get mapped to? A view? How does the getObjectById pass parameters to the query? How exactly does the query get executed?
..."
This might be done by a JDO vendor who mapped a user-specified SQL query to a JDO PC class. For example, if you have a DEPARTMENT table that you want to write an aggregate query for "SELECT D.DEPTID, MAX(E.SALARY) FROM DEPARTMENT D, EMPLOYEE E WHERE D.DEPTID = E.DEPTID".
You would map this query to a JDO PC class DepartmentMaxSalary which has a key field deptid and a non-key field maxSalary. The key class DepartmentMaxSalaryKey has a key field deptid.
Now, construct an instance of the key class:
DepartmentMaxSalaryKey dk = new DepartmentMaxSalaryKey(100);
DepartmentMaxSalary d = pm.getObjectById(dk);
System.out.println ("Department " + d.getDeptid()
+ " has max salary of " + d.getMaxSalary());
When the getObjectById is executed a hollow instance of DepartmentMaxSalary is constructed by the PersistenceManager. When the d.getMaxSalary() is executed, the implementation of the method accesses the maxSalary field which causes the PersistenceManager to executes the query and return the result into the field.
No implementation to my knowledge currently offers this kind of mapping, but certainly some will in future.
Regards,
Craig
|
|
|
Message #31283
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
John wrote:
"Is it necessary to pass an extent or collection to a query? Or will a query where neither is specified grab the default extent(all instances of a class in the database)?
"
Yes, the query is based on filtering an input collection. For convenience, the newQuery method that takes an Extent now does not take the Class of instances. So it is pretty easy to construct a Query with an Extent. The reason we didn't have newQuery(Class candidateClass) assume an Extent is that we also need the subclasses parameter, which we would have to get from either a parameter of newQuery or (as we do now) as a parameter of getExtent.
"Also, with respect to the PersistenceManager, why is the caching mechanism associated at this level? If a JVM has multiple PMs, then maintaining a synchronized state between their caches would seem to be much more difficult than if the caching were done at a higher level(PMFactory perhaps)."
Caching is done at the PersistenceManager level because concurrent transactions need their own versions of instances for isolation. If a JDO implementation "knows" about concurrency, it can itself manage cache coherency behind the scenes.
"Also, seemingly only a subset of the entire set of objects being cached within the VM will be available using the PM caching mechanism. Do you perceive these as problems as well? How can this be avoided, or what am I not understanding here?"
The JDO implementation is free to implement the caching to allow instances from a PersistenceManager cache to use a common VM-wide (or at least PersistenceManagerFactory-wide) cache to satisfy requests for values for persistent instances. But from the application perspective, it just sees persistent values.
Craig
|
|
|
Message #31336
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PrismTech roadshow with Craig Russell
FYI: I emailed this to sales@thoughtinc.com. Just thought folks might be interested.
To whom it may concern:
I have always considered evaluating CocoBase as a viable solution for my persistence needs, but, after reading Ward's highly charged and inflammatory, ranting post on theserverside.com regarding JDO, I have to admit that he has left a particularly bitter taste in my mouth.
I can understand a company disagreeing with a specification and its requirements, but to lambast JDO in such an unprofessional manner is inappropriate.
It was such an emotional reaction that I'm left wondering whether he posted his article out of fear. Don't forget that most enterprise software engineers are a pretty sharp bunch of people, and, thanks to all the Microsoft versus Java holy wars, can recognize unsubstantiated, emotional responses when they see them.
There is much support in the enterprise development community for JDO, and Ward has alienated many of them. Maybe you should have your company's high ranking officers think twice before unleashing such a barrage, especially when it can backfire so easily.
I'm anxiously awaiting Craig Russel's response.
Sincerely,
Matthew
|
|
|
Message #31377
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Craig,
Thanks for taking the time to respond to my email. It would seem that caching is not truly "done" at a PM level, more accurately is accessed there, and is implemented at the discretion of the programmer.
And, though I would hesitate to call the JDO spec embattled(seems awfully melodramatic), any thoughts on the controversy that is swirling around it?
John
|
|
|
Message #31449
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PrismTech roadshow with Craig Russell
I got a response from Thought. Here it is for all of you:
From: support@thoughtinc.com
Organization: THOUGHT Inc.
To: "Matthew T. Adams" <matthewadams@yahoo.com>
Date: Tue, 16 Oct 2001 12:47:53 -0700
Subject: Re: Ward Mullins and his post on JDO at theserverside.com
Reply-to: support@thoughtinc.com
CC: sales@thoughtinc.com
We're sorry to hear the email was such an unpleasant experience
for you, but let us assure you that we share that experience. The
first time we saw the rant from Craig on theserverside directly at
our company we were shocked. Then when he came and heckled
our staff at our booth at JavaOne we were dismayed. Then when
he started attacking us at Customer sites and internally at Sun (a
very good partner of ourse) we were blown away. The response
from Ward was VERY measured compared to all of the
unprompted, and unprofessional acts attempted to inflict on us.
We were still evaluating JDO, and because we had not come out in
favor of his specification he began to attack us.
After looking more indepth at the specification we could see why - it
stinks in its current form - (that's a technical term - stinks - by the
way :)
If you feel strongly about JDO, please lobby for the inclusion of our
technical feedback to the group. When we tried to give it to Craig
in the one actual direct interaction Ward had with Craig, he wouldn't
even listen to the technical points and basically just made it clear
he wasn't interested in our opinions.
If this is the sort of person you think should be heading up such an
important standards specification then there isn't much we can do.
Otherwise you're giving feedback to the wrong folks. We didn't
start this War, but we're not going to stand by and allow a 'hack' of
an architect to ruin the industry just because he doesn't know
anything... Remember we've successfully created the market
leader in O/R - Craig has never written a commercial O/R system -
and neither had ANYONE who was involved with JDO. If you don't
think we're justified in defending ourselves against a group that
won't respond to reason, won't take feedback and doesn't
understand the technology - then you don't understand that in fact
YOUR best interests are what we're watching out for. A bad
specification is a bad specification. To lie about it wouldn't do us,
or the customer or Sun any good. We tried to be political with our
feedback, but Craig made that route unavailable...
Thanks for your feedback, and we apologize that you feel so
affected personally by the conflict. You shouldn't let your emotions
however prevent you from evaluating or using the best product for
your needs. Otherwise aren't you doing that which you claim we're
doing?
THOUGHT Support
|
|
|
Message #31510
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Other O/R tools
If you're looking for a relatively cheap, well-implemented, and easy-to-use o/r tool, with excellent support and future jdo support, check out www.objectmatter.com.
They appear to be a company with a good, basic, o/r product but little marketing nous.
By the way, I am in no way associated with Objectmatter.
|
|
|
Message #31511
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PrismTech roadshow with Craig Russell
Anyone seen this rant that is mentioned in the reply? That's very interesting btw, Mr. Adams.
John
|
|
|
Message #31713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PrismTech roadshow with Craig Russell
With reference to postings by Thought Inc, my impression is that Thought spent a considerable amount of effort trying to make the JDO discussion personal instead of discussing the issues. IMO, this is unprofessional and inappropriate and, from my experience, is never a good sign.
According to Thought: “If you feel strongly about JDO, please lobby for the inclusion of our technical feedback to the group.” Can someone post Thought’s JDO technical feedback to the group? Thanks
|
|
|
Message #31729
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Other O/R tools
Gerhard,
Thanks for the tip...I downloaded the ObjectMatter VBSF software per your recommendation, and have been very pleased with it. We are still evaluating, but it looks like it may very well become part of the backbone of our development. I recommend it to anyone else out there who is looking for a solution to O/R mapping.
John
|
|
|
Message #31811
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PrismTech roadshow with Craig Russell
I haven't spent much time at all responding to JDO.
I think I've done 3 posts in the almost a year that Craig
has been personally attacking our product without actually
making a single technical reason for his attacks other than
he thinks JDO is what we should be using.
Remember Craig singled out our company on this site, and
attacked us and our products - we didn't start this flame
war - he did. Also note that he has at serveral times
directly contacted Forte customers and told them not to
use our products - not very ethical or probably even legal
in our merchanting law systems of the U.S.
He has also invaded partner meetings, heckled our personnel
at our own booth at JavaOne.
During that whole time I have only responded to his postings
or postings that stemed from it on this site. None of our
staff has ever heckled him or his staff. We have not
invaded his seminars, nor have we interfered with him as
he has spoken. The opposite cannot be true.
You're correct that there's a 'personal' vendetta going on,
but you might ask Craig why he has one? Why didn't he
involve THOUGHT Inc. in the JDO process? Why has he refused
to answer the technical responses and feedback from them on
the very real and serious technical limitations of JDO? Why
has he refused to recognize that JDO is an Object database
and not an Object to Relational database specification?
Perhaps because he used to work for one of the ODBMS vendors
and doesn't have experience with O/R Mapping?
Whatever the case - remember we didn't start this attack,
Craig did.
I honestly haven't had to waste much time on it, because
customers care about products that work, and that are
Transparent persistence. This is something that CocoBase
is, and that JDO is not!
Ward
|
|
|
Message #31845
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PrismTech roadshow with Craig Russell
For the second time, can you (or someone else from Thought) please post Thought's technical feedback that, according to Thought, it gave to the JDO group?
That will be much more productive use of everyone's time on this forum.
|
|
|
Message #31850
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
Hi ,
I'm using castor from exolab, an open source implementation of JDO (doesn't comply with the sun's spec), and it really shines. In my opinion, it is more reliable than the (today) sun's spec because castor is designed and intented to be used only with RDBMS storage (which is more or less 90% of today uses for datastores).
It's very simple of use. Just a xml descriptor for your persistent classes, no post compilation for your dataObjects, neither code modification for them. Just...use object oriented code to manage your data.It supports transactions, object caching etc (castor.exolab.org)
Furthemore, it provides a framework to make your objects persistable in a xml format (bi-directionnally), but i haven't used so much of this.
IMHO, where it really shines is for its implementation of their extended OQL query language wich really saved us time.
Try a look.
best regards,
Yves.
|
|
|
Message #31853
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Other O/R tools
John Kelvie, Re: ObjectMatter
No worries, mate. Glad to be of service.
As for the recent posts - yes, can somebody please post Thought's technical feedback so we can make up our own minds?
Gerhard.
|
|
|
Message #31868
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
A note with respect to Castor...I am not sure if they have made any significant changes to it of late, the last version that I used was 0.94 I believe, and the object to relational mapping had SIGNIFICANT problems. I don't mean a couple bugs...the one-to-many relationships just flat did not work. At the time, I sent an email to the castor-list suggesting that I would try to write some code to fix up the one-to-many relationships. I then began to dig into the code, which was a bit of hairball in the modules that handled turning oql into sql. I eventually just gave up after a day or two of dorking with the stuff, after seeing that the rewriting of the module was in order to fix the problems, not just a tweaking of a couple methods.
The specific problem I encountered, if I recall correctly, was that it did not make distinctions between one-to-one and one-to-many joins. It tried to do both in a single query(where a one-to-many join should really represent a separate query). Then when it brought the data back (and this is where my memory is a bit fuzzy), the retrieval then broke if there was MULTIPLE one-to-many relationships on a single object, since it tried to do all of these within a single query, which led to a cartesian product(imagine A has many B and many C...it would come back with A*B*C rows, which is wrong for obvious reasons).
This sort of fundamental problem really undermined my trust in the castor project. I think to call the version .94(meaning close to 1.0) when it cannot do one-to-many relationships correctly(in fact, the fundamental algorithm is flawed) is very misleading. I could of course be wrong about my understanding of the code, but this is what I experienced and what I saw, and I've been meaning to write a note to others about this, since they have put no mention of these flaws on their website that I have seen, and they are significant. Last I saw, one of the leads was proposing a "refactoring" of the sql retrieval modules, but by this point I had given up on it.
And I don't want to be too harsh on the Castor project. I would welcome any corrections to this. I would also suggest to them, that if what I am writing is correct, that try to bring a greater degree of transparency to their effort so that people such as myself do not spend time working with a tool believing it may be "production-worthy" when it in fact still has a ways to go.
John Kelvie
|
|
|
Message #31889
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Data Objects vs. Entity Beans
from what I gathererd a few months ago I can confirm this to a degree. Also note that Castor has been above the 0.9 limit for almost a year now.
Another free alternative which is committed to both ODMG and JDO (the former almost complete, the latter emerging) is ObjectBridge (http://objectbridge.sourceforge.net/). Have a look.
Christian
|
|
|
Message #32382
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thought Inc postings
Ward,
I honestly do not know where to begin to respond.
I have not made any personal attacks on any Thought personnel, on this site or any other.
I have not flamed anyone's product, especially a commercially successful one such as Cocobase.
I have not directly contacted Forte customers and told them not to use Cocobase products.
I have not invaded Thought, Inc. partner meetings, heckled their personnel at their booth at JavaOne, and have no idea how anyone would think it possible.
My interest is in discussing and debating the technical merits of Transparent Persistence, which I will do in a different message.
For now, I'd like to leave out the personalities and get to the issues.
For starters, perhaps a digest of the Thought, Inc. feedback on JDO would be useful?
Craig
|
|
|
Message #32385
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Transparent Persistence and Cocobase
I may be using obsolete information about Cocobase proxies and link managers here, and if so, please correct any inaccuracies.
The discussions with Thought, Inc. personnel have focused on where changes are required in order for applications to have changes made to memory instances of persistence capable classes reflected in the database.
JDO's concensus, widely discussed among the experts, has been that the application cannot know in advance how persistent instances will be manipulated, and should not be required to use wrapper instances of persistent instances, or use link managers to manage which persistent instances are in memory versus in the database.
Instead, JDO persistent instances notify their owning PersistenceManager if there is a reference to an instance not in memory, or if there was a change. The PersistenceManager will update the database when the application commits the transaction.
This is a strict separation of concerns between the persistence aware part of the application and the transparent persistence part. The persistence aware part needs to deal with queries, transactions, and the like. Everyone agrees that this part needs to have a persistence API, and this has been the subject of past attempts to standardize. However, the transparent part of the application, the business model domain, should not need any API for persistence.
With this separation, the business model classes are free to implement business logic using any of several strategies, including delegation, aggregation, and containment of persistence capable classes, without the requirement to update the application classes.
With JDO, the application does not need to use proxies or link managers, because the enhanced byte codes automatically allows the PersistenceManager to keep track of two things:
1. What part of the connected graph of instances has been fetched into memory;
2. Which fields of fetched instances have been modified in the transaction.
Solutions that require proxies or link managers are not transparent to applications, however close they may be.
This has been the major technical discussion point between JDO and Thought.
Craig
|
|
|
Message #32388
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thought Inc postings
Hmm... Put up or shut up huh? I thought that's what I
have been doing... Oh well maybe you haven't actually
read my posts...
Considering that I was actually present at the Forte
for Java Meeting, that I spoke to multiple customers who
had spoken either directly with you or one of your
co-workers on the JDO/JavaBlend group, and that I was
present at the JavaOne heckling - frankly I must say that
you're lying... It pains me to have to be so direct
publically, but you've given me no choice. Do I need to
start posting the names of Sun Employees who were present
at the meetings, or particular customers (think bank in
Switzerland) and who verify that you are in fact point
blank lying...
And lest we not all forget that this is your quote that in
fact does take a very personal swipe at our company:
"It's unfortunate that in order to promote its Cocobase
product, THOUGHT felt it necessary to make inaccurate
statements about competitive technology."
This is a quote from you on this forum, and was in fact
both unsolicited and was in response to a press release
and nothing we posted. In particular the press release
pointed out how CocoBase doesn't require either bytecode
or class inheritance changes - while JDO does. You may
consider the mutilation of .class files to be transparent,
but we don't. Also your comment that JDO doesn't require
'Serialization', neither does CocoBase. However most
distributed environments do - but considering that JDO has
no support for distributed environments, we're not suprised
you were unaware of that... The difference is that CocoBase
can persist any graph of objects, local or remote with no
object model invasions and mutilation of the .class files,
but JDO can't say the same. Our patented technology is
completely dynamic and non-intrusive and is an entire
different level of Transparent than has even been proposed
for JDO. If you had taken the time to actually know what
we offered, your above statement might have had a more
humble tone, and not been so arrogantly stated... Also
JDO is supposed to be a specification and not a competitive
technology, unless you count Javablend Done Over that ships
with Forte...
Now I don't know why you're lying other than either
embarrassment or managerial pressure, but the fact is that
you are... There are several physical witnesses to your
escapades, including customers, so while I understand that
your ego is getting in the way of you apologizing, it isn't
doing you any good... We're here for customer and vendor
success, and would have loved to work with you on this, but
instead of talking to us as partners, you criticized,
belittled and bemoaned our products and our offerings.
Now as for the technical merits of JDO, I've been telling
both you and customers about this for a long time, but
you haven't been listening. You act as though this is all
new information and that somehow we aren't talking, but as
the postings on this forum indicate - I've actively been
giving JDO feedback to you. If you search on this board
and on forum.thoughtinc.com you'll find lots of responses
from me on various technical issues.. Here are a couple of
highlights however that are show stoppers in the current
JDO.
1) JDO isn't transparent because the Object is both self
aware of persistence and manages it through either bytecode
manipulation or inheritance/implementation changes. In
either case, it's intrusive, non-transparent, difficult to
debug, decreases instance reusability, limits a single
instance per single database, etc. etc. etc.
2) JDO doesn't implement QueryByExample basically pushing
customers back to embedded queries. The current OQL model
is great for ODBMS vendors, but screws Oracle, Sybase, DB2
and every other Relational vendor because of double querying
that must occur. Considering your background at Versant
and ODMG firmly places your experience as an ODMG engineer
I'm not suprised that you're probably unaware or don't care
about this. However most new development and most existing
data is in RDBMS systems - and this requirement is really
bad for those customers. It also means customers will get
killed on performance with the supposedly fast JDO in the
real world of O/R mapping. Actually if we were really
vendictive we would sit quietly and allow all of our
competitors implement JDO & OQL, and them simply have
customers run a performance test. It's unlikely we would
never lose an account - oh but wait that's what we already
do :)
3) You're limited to an instance belonging to a single
Transaction - this screws enterprise customers who wish to
either move data to alternate instances or replicate data
through java APIs. This is a very small percentage of
customers, but they are enterprise customers, and there's
no way JDO can be used for them in it's current state
making the claims of JDO as an Enterprise solution quite
incredible.
4) JDO focused purely on the ODBMS vendor (it's very obvious
from both the design and focus of the spec), and therefore
has absolutely no specifications for O/R mapping included
in it. It's being pushed as a specification for O/R
mapping, but it doesn't contain any specifications for
O/R mapping. It only covers how an instance should talk to a
Resource Manager, and how OQL should be used for queries.
I find this horribly disturbing and disappointing.
5) The specification isn't compatible with distributed
environments despite the fact that most programming that is
done now has some distributed component to it. There is no
notion of instance reconciliation, relationship graph
management, instance insertion ordering, etc. There is a
complete lack of understanding of how most customers use
databases in applications. The JDO spec looks almost
identical to the ODMG spec from 5 years ago, and it was an
out of date specification then... There's a reason that
ODBMS never succeeded in Java O/R mapping - it was a
completely bogus design for Java & runtime environments.
Nothing has changed unfortunately in the spec that's even
worth mentioning, yet the industry has moved forward in
so many ways that it's amazing! ODMG is asleep at the
wheel and JDO reflects this...
6) The specification doesn't deal with basic issues such as
sequence generation, O/R mapping, relationship management,
instance copies. It doesn't focus on non-intrusive instance
management, replication, caching, distributed programming,
integration with EJB, including Entity, Session, & JSP and
servlet usage.
Basically it's a 0.1 specification in a 4.0 industry...
I'm glad you're interested in improving JDO, but you have
about 5 years of technology improvements to just be on the
level of current industry needs, and it's continually
evolving. The ODMG/JDO specification doesn't reflect any
of those new industry requirements and is completely
stagnant and out of date in its agenda... Until you involve
companies such as ours that are leading the current wave of
innovation, then JDO will be as much of a backwater
specification as ODMG has been...
Do I have a commitment from your group to actually drop
your ODMG preconceptions and listen to real industry &
relational database requirements? Do I have a commitment
from you that you will no longer attempt to sabotage both
our working relationship with other companies including
customers? Do I have your commitment that you will listen
openly to our feedback and actually incorporate it into the
specification? Do I have your commitment that your real
agenda isn't to try to undermine O/R vendors with your
failed JavaBlend product masquerading as JDO? Do I have
your commitment that you guys will stop heckling us at
trade shows and online? Do I have your commitment that
you will give us the same level of inclusion in your
process that you give your own Javablend engineers and
ODBMS vendors? Do I have your commitment that you will
stop promoting JDO as an O/R specification until it has
O/R features?
Those are the sort of things I would need from you before
I would begin to trust that you would do what you say you're
going to do. Especially in light of my current distrust
for anything you say since you just blatantly are lying at
this point...
Just my $.02
Ward Mullins
CTO
THOUGHT Inc.
http://www.thoughtinc.com
|
|
|
Message #32389
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Transparent Persistence and Cocobase
" Solutions that require proxies or link managers are not transparent to applications, however close they may be."
Oh that's very preachy but wrong. The application code
is basically identical between CocoBase and JDO. The
difference is that developers can use objects on the fly,
having never seen them before, and with arbitrary mappings
and models. Your assessments about this is sooo off the
mark that it is laughable... Also unlike JDO, the Proxy
approach doesn't require ANY object model changes, no byte
code manipulation or object model changes. Where JDO feels
it's OK to invade both the Application and the object model
to achieve transparent persistence, CocoBase insists that
it's only necessary to invade the application. And in all
honesty the way CocoBase does it is almost identical to
how JDO does it, so you don't have a leg to stand on in
this argument... It's a fabricated argument from someone
who's obviously never implemented something with a tool
like CocoBase...
In addition the CocoBase system is much simpler than the
JDO method because it's also network compatible. The same
technology works locally, across session or entity beans,
across CORBA... CocoBase can persist an entire object graph
on a remote Session Bean service with a simple call like:
sessionbean.save(myObj);
It's pretty hard to beat that level of transparency no
matter how you try.
You couldn't be any more ill informed if you tried be on
this issue...
Now my concern is why you feel that you HAVE to implement
using an object mutilation approach - shouldn't you allow
customers to have the option of doing either? Shouldn't
you allow existing, mature, stable and enterprise products
like CocoBase work in the same fashion they always have
to satisfy these issues? Your approach is immature by
contrast, yet you are completely hell bent on this is the
only way - it's irrational... It's completely irrational
on your part....
Ward Mullins
CTO
http://www.thoughtinc.com
|
|
|
Message #32452
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thought Inc postings
Ward sez:
And lest we not all forget that this is your quote that in fact does take a very personal swipe at our company:
"It's unfortunate that in order to promote its Cocobase its Cocobase product, THOUGHT felt it necessary to make inaccurate statements about competitive technology."
The facts:
I did say that. I don't agree it is a very personal swipe, just a response to your misstatements. I don't know why you choose to treat it as personal.
Ward sez:
This is a quote from you on this forum, and was in fact both unsolicited and was in response to a press release and nothing we posted. In particular the press release pointed out how CocoBase doesn't require either bytecode or class inheritance changes - while JDO does.
The facts:
JDO does not require inheritance changes, and doesn't require bytecode manipulation (although many users will find this to be very neat and clean compared to alternatives).
Ward sez:
JDO doesn't implement QueryByExample basically pushing customers back to embedded queries.
My opinion:
Query by example is superficially neat but has real issues. One example is how to specify that you want to find instances of Department without any Employees, where the object model you are querying has a Collection field containing Employee instances. You need a special way to indicate that the emps field is empty, and a special way to perform existence queries on navigation.
Ward sez:
The current OQL model is great for ODBMS vendors, but screws Oracle, Sybase, DB2 and every other Relational vendor because of double querying that must occur...
The facts:
JDO does not use the OQL model. It uses a Java boolean expression for queries, which by design allows for extremely efficient queries in relational back ends. No double querying needs to occur.
Ward sez:
You're limited to an instance belonging to a single Transaction - this screws enterprise customers...
The facts:
JDO supports several caching policies, including non-transactional caches that can be shared among many transactions.
Ward sez:
JDO focused purely on the ODBMS vendor...
The facts:
The JDO expert group includes many object-relational vendors. Check out the JDO web site for a partial listing.
Ward sez:
The specification isn't compatible with distributed environments...
The facts:
There is at least one shipping JDO preview implementation that supports J2EE Session beans and BMP Entity beans. The architecture provides for distribution but doesn't mandate it.
Ward sez:
The specification doesn't deal with basic issues such as sequence generation, O/R mapping, relationship management, instance copies.
The facts:
Sequence generation and O/R mapping are basic issues for object-relational mapping, which JDO by design is not a specification for. A future release of JDO will likely address these issues. For now, JDO vendors will handle these issues in a non-standard way, with the intent to standardize them in a future release.
JDO focuses on the Java view of databases, and allows for JDO implementations to be built on simple file stores, relational databases, object databases, hierarchical databases. It does not contain mandatory features found only in relational databases.
Ward sez:
It doesn't focus on non-intrusive instance management, replication, caching, distributed programming, integration with EJB, including Entity, Session, & JSP and servlet usage.
My opinion:
I guess we just disagree.
Craig
|
|
|
Message #32466
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Craig lies again...
To Craig:
I love how you always state things as 'The facts' and yet
you always seem to leave 'the facts' out of your statements.
Craig says:
" I did say that. I don't agree it is a very personal swipe,
just a response to your misstatements. I don't know why you
choose to treat it as personal. "
Response (the facts):
Actually there was nothing incorrect in our statements about
JDO, yet you 'accuse' our company of maligning you in order
to further our product. When in fact the shoe is on the
other foot...
" Craig Says:
JDO does not require inheritance changes, and doesn't
require bytecode manipulation (although many users will find
this to be very neat and clean compared to alternatives). "
Ward's response:
You're lying. JDO either requires bytecode manipulation or
the customer invade their object model with interface
implementations (inheritance). You're hiding behind
semantics and lying to the public. It's very sleazy...
Craig Says
"My opinion:
Query by example is superficially neat but has real issues.
One example is how to specify that you want to find
instances of Department without any Employees, where the object model you are querying has a Collection field
containing Employee instances. You need a special
way to indicate that the emps field is empty, and a special
way to perform existence queries on navigation."
1) Actually there are several ways of doing this with QBE...
2) QBE can be extended with Query Builders that use native
Syntax and that don't incur parser overhead...
3) QBE can be used with multiple mappings and actually
present 'views' of information.
4) Why didn't you ask these questions of us 2 years ago
instead of telling us we're wrong...
Craig says:
"The facts:
JDO does not use the OQL model. It uses a Java boolean
expression for queries, which by design allows for extremely
efficient queries in relational back ends. No double
querying needs to occur. "
This is in fact OQL, just a subset of it - and it does
require parsing... Just because you don't support the
full OQL syntax, doesn't mean you aren't doing OQL or
that parsing isn't involved. This is pure spin...
"Craig says"
The facts:
JDO supports several caching policies, including
non-transactional caches that can be shared among many
transactions. "
This is not the same thing, but I'm not suprised that you
aren't aware of it. Caching and multiple transactions doing instance tracking of the same instance
are entirely different. CocoBase supports both, JDO
doesn't.
"The facts:
The JDO expert group includes many object-relational vendors. Check out the JDO web site for a partial listing. "
Yes and none of the market leaders were involved in the
creation of JDO. You built the spec in a bubble, and now
you attack vendors who point out how crappy it is...
The specification isn't compatible with distributed environments...
"The facts:
There is at least one shipping JDO preview implementation
that supports J2EE Session beans and BMP Entity beans. The
architecture provides for distribution but doesn't mandate it. "
Really? And do the session beans allow for client copies
and reconciliation of instance graphs? This is spin...
The spec isn't compatible. Vendors can always work around
the spec and provide compatibility outside of it, but its
not because the spec allows it.
"The facts:
Sequence generation and O/R mapping are basic issues for object-relational mapping, which JDO by design is not a specification for. A future release of JDO will likely address these issues. For now, JDO vendors will handle these
issues in a non-standard way, with the intent to standardize them in a future release. "
If you had only said this a year ago things would have
been different...
Please note everyone that reads this the very key phrase
that Craig says. It's the first time I've ever seen him admit this publically. Please read above he very clearly
says:
"JDO is not a specification for object-relational mapping"
So Craig stop promoting JDO as a specification for Object
Relational mapping!!! You're confusing customers, pissing
off vendors and really screwing up Java persistence. JDO
technology needs drastic changes before it will be useful
for Enterprise O/R mapping - so stop trying to push this
premature technology into enterprise accounts. It isn't
ready, and it will screw everyone involved...
Craig Says:
"JDO focuses on the Java view of databases, and allows for
JDO implementations to be built on simple file stores,
relational databases, object databases, hierarchical
databases. It does not contain mandatory features found only in relational databases. "
No offense Craig, but CocoBase is the only product that was
implemented in java that actually did all of these things.
We used to sell ODBMS & Mainframe versions of the CocoBase
product, so the exclusion of our unique feedback from this
and the arrogant responses you always give us make us
really opposed to your efforts. Your arrogance and catty
attacks at us has inflamed my sense of right and wrong and
I'm sick of your sabotaging tactics. If you want to build
an O/R specification, then great, but a generalized
persistence specification that is not focused on O/R
mapping is stupid and out of touch with reality..
Craig says in response to us saying JDO is intrusive:
"My opinion:
I guess we just disagree. "
Craig you're wrong. You cannot import and use an object
model with JDO without either changing the source code or
the binary for JDO use. This is intrusive despite your
uneducated opinion to the contrary. If the customer must
either bytecode mutilate their classes, or require changes
to the inheritance and implementation infrastructure then
in fact you're wrong...
Just my $.02
Ward Mullins
CTO
THOUGHT Inc.
http://www.thoughtinc.com
|
|
|
Message #32496
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Craig lies again...
Ward, do you really understand the personna you are putting out and how this reflects on your company?
I work for Versant, yes an ODBMS vendor, and have been active in the JDO expert group. I also know Craig and have found him to be very agreeable and not as you portray him. You may say I am biased (being from one of those nasty ODBMS vendors that you seem to think so little of) and discount what I have to say, so be it. But I feel someone from the expert group, other than Craig, should add to this discussion and try and set the picture straight.
Thought Inc. is not part of the expert group, which is a shame. However, many people from lots of different arenas other than ODBMS have joined the group and have contributed to JDO. Thought Inc. could have easily joined, but you choose not to, if you had you would have had an equal voice along with the rest of us. Craig does not have the ultimate say on what JDO is, I would hope other expert group members would agree that the decisions are by consensus not by Craig. Craig simply heads up the initiative. This is not a SUN sponsored standard it is part of the JSR process, it is sponsored by those of us that belong to the expert group and have been working since 1999 to develop a standard for "transparent object persistence" within Java.
To be honest, from my biased perspective you are as guilty as you claim Craig is with respect to making claims not entirely based on fact. When I read your comments on JDO I'm afraid I can't but help feeling you haven't really taken the time to investigate it and instead have made a snap judgement (based on your dislike for ODMG) that it isn't what CocoBase does today and therefore it is rubbish. Many of your comments just are not based on fact I'm afraid.
However, I took the time to download your product, hope you don't mind, so I could get an up todate view of how CocoBase works and compare this to what I know of JDO to try and understand where you are comming from.
1) The first question is "transparency", you claim JDO is bad because it mandates bytecode enhancement or at least changes to the class hierachy. On looking at your developer guide, the section on "Persisting a Java class to a database" it seems to indicate I can do this with CocoBase a number of ways, quoting from your document (again I hope you don't mind):
"This can be accomplished by implementing a standard set of CocoBase compatible interfaces, or by using some Proxy/inheritance/subclass which provide access to the attributes of each instance."
Forgive me if I have this wrong, but how can you say JDO is bad because it requires the inhertiance/implementation changes when CocoBase advocates the same as its default mechanism? I agree the Proxy approach you offer, which avoids implementing an interface, is something JDO doesn't support but in my mind could very easily be done whereby the Proxy simply is an implementation of PersistenceCapable that generically wraps any class. The downside of this, as with CocoBase, is that the data members have to be public...and I personally feel this is not such a good thing, maybe its just an OO purist thing.
Now the question of bytecode enhancement. JDO doesn't mandate this, all it says is that the class should implement PersistenceCapable and in fact we had a recent discussion in the expert group about how we could support different non-bytecode enhanced implementations, | |
