So which "real projects" have you used JDO in? I'd be interested in knowing how it compared to OJB. What JDO impementation did you use?
Yes, feel free to call CocoBase crap, because you have actually used it. I have no problem with people criticizing when they know what they are talking about.
When you say that you don't like the enhancer, it's important to provide some information on why you don't like it. Otherwise your post could be misinterpreted. One might even think you have never used JDO.
The enhancement process is a major advantage of JDO's architecture, as I explained in my previous post. The implementation of JDO I used was Kodo from Solarmetric, and the reference implementation, though that is not as relevent.
I have not used Cocobase or Toplink on real projects (I have experimented), which is why I did not comment on them, nor make negative references to the open source varients.
here we go with the FUD again. "Mangler"??? I suppose you consider javac a "mangler" or aspectj a "mangler".
I think the "mangler" you refer to is the bytecode enhancer. What you forgot to mention is what the "mangler" does. Rather than scare people off, I'd like to explain the clear advantage to bytecode enhancement over reflection for dirty detection.
Let's say you do a query which returns a single object. Your application then modifies a single field of the object and commits the transaction.
Before commit you have to perform "dirty detection" to find out what fields have been dirtied, and need to be updated in the DB.
If you don't use an enhancer you have to compare the object, field by field, with either a cached copy of the object, or worse, issue a select into the database to get the old values. The latter is particlularly bad not just for the obvious performance hit, but because it forces the table or rows to be locked for the duration of the transaction, thus making optimistic transactions impossible. Now imaging your select returned 100 objects, or 1000 objects.
With an enhancer, the bytecodes for 'putfield' and 'getfield' are replaced with calls to the bvendor provided state manager. The JDO driver knows instantly what fields were dirtied, needs to keep no cached copies and never hits the database with a select before update.
Furthermore, with enhancement you don't force the user to extend any classes. There is zero intrusion on the domain model.
I understand that Castor, Hibernate, etc. are good open source projects, and very viable. I do, however, think that JDO is elegant and has advantages, on paper at least, over other methods.
Slashdot Mirror
I would listen to Patrick ... I think he might have some experience with JDO ;)
So which "real projects" have you used JDO in? I'd be interested in knowing how it compared to OJB. What JDO impementation did you use? Yes, feel free to call CocoBase crap, because you have actually used it. I have no problem with people criticizing when they know what they are talking about. When you say that you don't like the enhancer, it's important to provide some information on why you don't like it. Otherwise your post could be misinterpreted. One might even think you have never used JDO. The enhancement process is a major advantage of JDO's architecture, as I explained in my previous post. The implementation of JDO I used was Kodo from Solarmetric, and the reference implementation, though that is not as relevent. I have not used Cocobase or Toplink on real projects (I have experimented), which is why I did not comment on them, nor make negative references to the open source varients.
here we go with the FUD again. "Mangler"??? I suppose you consider javac a "mangler" or aspectj a "mangler". I think the "mangler" you refer to is the bytecode enhancer. What you forgot to mention is what the "mangler" does. Rather than scare people off, I'd like to explain the clear advantage to bytecode enhancement over reflection for dirty detection. Let's say you do a query which returns a single object. Your application then modifies a single field of the object and commits the transaction. Before commit you have to perform "dirty detection" to find out what fields have been dirtied, and need to be updated in the DB. If you don't use an enhancer you have to compare the object, field by field, with either a cached copy of the object, or worse, issue a select into the database to get the old values. The latter is particlularly bad not just for the obvious performance hit, but because it forces the table or rows to be locked for the duration of the transaction, thus making optimistic transactions impossible. Now imaging your select returned 100 objects, or 1000 objects. With an enhancer, the bytecodes for 'putfield' and 'getfield' are replaced with calls to the bvendor provided state manager. The JDO driver knows instantly what fields were dirtied, needs to keep no cached copies and never hits the database with a select before update. Furthermore, with enhancement you don't force the user to extend any classes. There is zero intrusion on the domain model. I understand that Castor, Hibernate, etc. are good open source projects, and very viable. I do, however, think that JDO is elegant and has advantages, on paper at least, over other methods.