Cocobase claims true distributed transparent object persistence

Discussions

News: Cocobase claims true distributed transparent object persistence

  1. Thought Inc., maker of the Cocobase object to relational mapper for EJB application servers has announced a significant advances in transparent object persistence features. The idea is that you can work with plain java classes (not entity beans) and they could be persisted to a database without any extra code (similar to the new JDO spec).

    Press Release:
    -----------------------
    THOUGHT Inc., the market and technological leader in Object to Relational Mapping OPTIMIZED for EJB, today announced exciting advances in Transparent Object Persistence features in CocoBase Enterprise O/R for use with EJB and Java Classes. Persisting complex data object graphs in both a local and distributed environment is greatly simplified to a few lines of code. This is accomplished dynamically thus not polluting the object graph allowing for optimal continued reuse. Ward Mullins CTO, of Thought Inc. summed up the company's philosophy in a news conference today in this way, "To the Object Model do no harm."

    It is important to compare and contrast this development with existing systems such as ODMG and JDO. These specifications say that the APIs are open, however, in order to achieve a practical implementation the result becomes proprietary and vendor specific. This means that either the class must be rewritten by hand or rewritten by some tool to be compatible with their systems. The increased complexity and developer time to create and maintain such a large code base can quickly become unreasonable.

    CocoBase's architecture by contrast doesn't require CocoBase code to be inserted into the objects or the object graph. Therefore reprocessing of source code or byte code in order to persist the objects does not occur. Instead, the CocoBase product can persist an entire graph of objects created elsewhere with no changes to either the object source or binary code.

    Both ODMG & JDO require changes to the source or binary code of the objects. These approaches are both unnecessary and often increase error-prone code to an unacceptable level. Many consider the designs of ODMG and JDO to be counter to Java's open access - cross platform - component reuse design intent. While CocoBase's architecture makes java classes vendor neutral, the other approaches deeply tie the source or binary code to only one vendor. Their system creates a java class hierarchy that once processed and integrated by one vendor becomes completely incompatible with another.

    This latest generation of CocoBase's technology can identify 'copies' of objects and parts of object graphs, and manage them in both a local and distributed environment. Entire graphs of objects can be copied to some remote machine, manipulated and then processed in some form to be returned synchronized with the original and the copy. CocoBase, using this facility, can manage virtually any serializable object graph.


    About CocoBase Enterprise O/R

    CocoBase Enterprise O/R provides EJB developers templates for Container and Bean Managed Persistence that are optimized for scaling and performance with full support for EJB 1.0, 1.1 and the anticipated 2.0. The generated CMP, BMP, JSP code, like most of CocoBase Enterprise O/R, can be extended or changed based on the customers unique requirements without having to involve costly consulting. This fine grained Object to Relational mapping and dynamic code generation provides the developer consistent, high-end database access across any standard EJB Server with the ability to manage complex relationships between Entity beans and Non-Entity beans, and access to any standard Relational database.

    About Thought Inc.

    Established in 1993, THOUGHT Inc. is the market leader in Java-based object-oriented Mapping Middleware technology. THOUGHT Inc. has been shipping CocoBase, the patented flagship product and the industry's most advanced framework for accessing legacy data in a distributed application since March of 1997. CocoBase is a standards based product relying on such technologies as RMI, CORBA, JDBC, EJB, etc. Thought Inc. makes its home in San Francisco supporting customers worldwide in the United States, Europe, Japan, Asia and Australia. CocoBase and THOUGHT Inc. are registered trademarks of THOUGHT Inc. CocoBase technology is based on US patent #5857197. More information on THOUGHT Inc. can be found online at www.thoughtinc.com.

  2. In their press release, THOUGHT has made some comments on JDO that just aren't true.

    THOUGHT sez: "It is important to compare and contrast this development with existing systems such as ODMG and JDO. These specifications say that the APIs are open, however, in order to achieve a practical implementation the result becomes proprietary and vendor specific. This means that either the class must be rewritten by hand or rewritten by some tool to be compatible with their systems. The increased complexity and developer time to create and maintain such a large code base can quickly become unreasonable...While CocoBase's architecture makes java classes vendor neutral, the other approaches deeply tie the source or binary code to only one vendor. Their system creates a java class hierarchy that once processed and integrated by one vendor becomes completely incompatible with another."

    RESPONSE: This betrays ignorance of the JDO specification. JDO requires that the persistence-capable classes be *binary compatible* with all persistence-capable classes from all JDO vendors, including the freely available binary distribution of the JDO Reference Implementation. Part of the test suite for JDO compliance is verifying that the JDO implementation operates correctly with the Reference Enhancement of application classes.

    The reason JDO inserts special code into the persistence-capable classes is two-fold:

    1. Changes to persistent fields are automatically detected and reported to the PersistenceManager responsible for the instance. This allows for extremely efficient change management. The alternative of "diffing" two object graphs is very inefficient.

    2. Navigation off the edge of an object graph transparently can only be done by detecting references to uninstantiated parts of the graph. This is not an issue if your object graphs are small, and can be bounded easily; but if your object graph is highly connected then the closure of the graph can easily be most of your database. This will be the case if you naturally map from a relational database to a Java object model. Most of the tables are related (hence the term "relational") directly or indirectly to most of the other tables in a schema. Constructing "islands" of object graphs is an anomaly.

    THOUGHT sez: "Instead, the CocoBase product can persist an entire graph of objects created elsewhere with no changes to either the object source or binary code."

    RESPONSE: This exposes the developer to the same issue as with Serialization as a persistence mechanism. You get an object graph of instances to ship around, and deal with the entire graph for purposes of change detection.

    If you assume that the object graphs are Serializable, you are artificially constraining the problem to those Java classes that either themselves implement the serializable interface methods, or can use default serialization.

    But JDO allows transparently storing instances of classes that do not support serialization, and for classes that are serializable further allows identifying fields in the object model as being transient for serialization purposes but persistent for storage in the database. This solves the issue of serializing the entire database, if you have a natural Object Model.

    THOUGHT sez: "The increased complexity and developer time to create and maintain such a large code base can quickly become unreasonable."

    RESPONSE: The complexity of enhancing a Java .class file is on the order of compiling the file. There's no extra code for the developer to manage; it's just an extra step during either development or deployment (depending on the tool). And if you enhance using one tool, you are done. The classes can be used with any JDO vendor's implementation.

    THOUGHT sez: "Many consider the designs of ... JDO to be counter to Java's open access - cross platform - component reuse design intent."

    RESPONSE: Besides yourselves, can you be more specific? Highly-placed sources within the industry, speaking on deep background, perhaps?

    It's unfortunate that in order to promote its Cocobase product, THOUGHT felt it necessary to make inaccurate statements about competitive technology.
  3. Mr. JDO's response to THOUGHT[ Go to top ]

    You go, Craig.

    I've been using the ODMG Java binding for a number of years, and, once I overcame the addmitedly uncomfortable notion of my source code executing more than what I wrote, I sat back and enjoyed the productivity. I've been aching for a persistence story that integrates with EJB transactions and security, and JDO (along with JCA) is it.

    I am seeing more and more where folks are simply abandoning entity beans in favor of direct database manipulation via session beans; my personal wish a couple of years ago was to use mainuplate fine-grained persistence capable classes in session beans, where my session beans represented services.

    The only system I've seen that I was impressed by because of its persistence story was GemStone/J, but now that Brokat has killed it, it's really not an option until someone else (or Brokat) resumes the industry's faith that they will continue the product. GemStone/J's JVM had the persistence code in it, so that there was no class enhancement; the tradeoff was that you had to use their JVM.

    Anyway, I would strongly, strongly encourage proponents of entity beans to check out the ODMG Java binding (a great implementation is Poet's, www.poet.com, with a great trial product) as well as JDO, comparing specifically the amount of code that the developer is forced to look at. With enhanced classes, you leave the persistence code to the experts of persistence, and the business object code to the experts of business objects.

    How much fun is it to write an O-R mapping layer yourself, anyway? For me, not very much. Furthermore, the cost your company will incur in developer & tester time to write one O-R mapping layer for one object model will probably exceed what it costs to buy your persistence capability that will work for all object models.

    Sometimes I wonder whether entity beans were thrown in to one-up the competition (Microsoft Transaction Server). After all, session beans have a high degree of correlation with MTS components (often stateless, short in duration, accessing managed resources, and propogating transaction and security contexts).

    Anyway, that's my $0.02.

    --Matthew
  4. Mr. JDO's response to THOUGHT[ Go to top ]

    I think entity beans were added to provide an component-oriented representation of business objects .. something that MTS doesn't have (MS has never been very object-centric). Unfortunately, Sun really underestimated (imho) the problems with integrating with a datastore, hence the problems with both BMP and earlier versions of CMP.

    Regarding GemStone/J, I agree it was really one of the best solutions for transparent persistence -- and from what I've heard they're going to spin the cache out into a separate product (hopefully)... I'd really like to see the smalltalk product preserved too (or open sourced)...

    But, more on topic, transparent O/R mapping is something TopLink has been doing for quite some time.. it requires no post-processing, just a configuration file. It scans changed fields and compares the changes with a snapshot to determine the SQL statement.

    On the bright side, this is good for CocoBase, as the main problem I've had with it in the past is the gobs of generated code it used to require.
  5. Mr. JDO's response to THOUGHT[ Go to top ]

    Hi Stu,

    Thanks for the response.

    We like the GemStoneJ solution quite a bit because it is
    non-intrusive into the bytecode. We told the founder of
    ODMG when he was on his JavaBlend kick that bytecode
    invasiveness was a really lame idea for Java. We still
    believe it to be true, and just to demonstrate it at the
    time we actually built a Transaction object that mimicked
    the ODMG APIs, but wasn't restricted to its limitation.

    The ironic part is that our solution is incredibly similar
    to the JDO/ODMG Transaction API behaviors, it just does it
    without any object model intrusion.

    We're aware of this from Toplink. We actually were the
    first vendor we were aware of to do this model. At the
    time we introduced it Toplink still required proxy objects
    to navigate and we built an external system (about 3 years
    ago) to navigate. What we've done recently is to take that
    to the next level by allowing simultaneous models to
    dynamically be used with the same application and thereby
    'morphing' behavior in terms of lazy/non-lazy loading, etc.
    And to do it for very complex object models that can either
    be local or distributed. So we can do things like transfer
    the entire object graph (with cycle detection) to a client
    from an Entity or Session bean, work on the local copies
    and transfer the copies back to the server in a single
    network call if we wish to commit the changes. This offers
    significantly better performance than the traditional
    EntityBean model.

    You mention about gobs of our own code, you may have missed
    our 'generic' code generation targets and CocoNavigate
    system. This has been evolved into what we call the
    Navigator which is an 'instance' based navigation system
    that's well suited to working inside J2EE containers as
    well as locally in applets/applications...

    We can also generate these models out of an existing UML/XMI
    model in seconds and immediately persist the java classes
    without any intrusion into the model or bytecodes...

    This also means that customers can do things like build
    generic 'session' beans that can manage any number of new
    java objects on the fly without actually having to write
    specific management code. It GREATLY simplifies network
    programming with complex object models...

    Thanks for your posting and if you haven't taken a look at
    CocoBase in a while you might want to give it a spin!

    Ward Mullins
    CTO
    THOUGHT Inc.
  6. Craig sez:
    "This betrays ignorance of the JDO specification. JDO requires that the persistence-capable classes be *binary
    compatible* with all persistence-capable classes from all
    JDO vendors, including the freely available binary distribution of the JDO Reference Implementation. Part of
    the test suite for JDO compliance is verifying that the JDO
    implementation operates correctly with the Reference
    Enhancement of application classes. "

    THOUGHT Response: Actually the minute the java classes
    are processed and used by a given vendor, no other vendor
    can use those instances. Also the classes must be either
    bytecode manipulated or inherit from a class hierarchy to
    persist them with JDO. With CocoBase no such manipulation
    or 'enhancement' is necessary. Part of what we were
    referring to is the fact that CocoBase can interoperate on
    pre-existing pure object model generated unmanipulated java
    classes that any number of other vendors can simultaneously
    use. So for example we work with the Javlin product which
    does ODMG byte code manipulation, and we can in fact track
    and persist instances that are being managed simultaneously
    by Javlin. Similarly we can co-exist with 'copies' of
    objects, not just raw instances. This 'non-intrusive' model
    is more appropriate and less intrusive than your
    specification which isn't necessary for Java or O/R mapping
    although it probably is useful for C++ or object databases..

    Craig sez:
    "The reason JDO inserts special code into the persistence-capable classes is two-fold:

    1. Changes to persistent fields are automatically detected and reported to the PersistenceManager responsible for the
    instance. This allows for extremely efficient change
    management. The alternative of "diffing" two object graphs is very inefficient. "

    THOUGHT Response:
    This is a very misguided and inaccurate assumption from many
    perspectives. While notification might 'academically' seem
    like it's more efficient at first, but in fact with a
    network the overhead of dinking the server for every little
    change is ridiculously high overhead, and means that there
    will be a round trip network connection for every
    single attribute changed or changed back no matter whether
    those changes are committed or not...

    The assumption that 'diffing' objects is very slow.
    While some implementations might be relatively slow,
    ours isn't. It's also much faster to diff a graph than to
    even make a single network call often, so these assumptions
    aren't very real or very accurate. If we had been consulted
    on this issue, then we could have cleared this up before
    it became the prevailing wind around this specification.
    As always there are many ways of accomplishing tasks, and
    as it happens ours just happens to be very efficient.

    Craig sez:
    "2. Navigation off the edge of an object graph transparently
    can only be done by detecting references to uninstantiated
    parts of the graph. This is not an issue if your object
    graphs are small, and can be bounded easily; but if your
    object graph is highly connected then the closure of
    the graph can easily be most of your database. This will be
    the case if you naturally map from a relational database to
    a Java object model. Most of the tables are related (hence
    the term "relational") directly or indirectly to most of
    the other tables in a schema. Constructing "islands" of
    object graphs is an anomaly. "

    THOUGHT Reponse:
    Wow this is such an inaccurate and unsubstantiated statement
    that I don't know where to begin. First of all just because
    there's a relationship doesn't mean it has to be loaded.
    The lazy load model is quite common from O/R vendors and
    totally destroys any concerns about this. Perhaps issues
    such as this haunt ODBMS vendors, but not O/R layers such
    as CocoBase which lazy load quite nicely.

    Developers do not need to load an entire complex graph
    of objects from a relational database to build any
    application in java. It's quite appropriate and normal
    for them to lazy load only those portions of a graph
    that they may need at any point in time. Most developers
    who've built a distributed or even local app understand
    this completely.

    Not only is this an irrelavant statement, but if this is
    the justification for model intrusion it should be revisted
    and the thinking should be radically adjusted...
    This is not a real issue in the real world...

    Craig sez:
    "This exposes the developer to the same issue as with Serialization as a persistence mechanism. You get an
    object graph of instances to ship around, and deal with the
    entire graph for purposes of change detection. "

    THOUGHT Response:
    That's wrong. Maybe that's how some developers less
    familiar with O/R might have initially implemented
    this, but it's not how CocoBase works. It sounds like the
    folks who built JDO are more familiar with ODBMSs and
    aren't very familiar with Java O/R tools based on this
    posting.

    CocoBase can automatically ship around any instance from an
    object graph or the whole graph. And as for how efficient
    the whole graph is in being processed, it's much more
    efficient than you think and it's much more efficient than
    the ridiculous JDO model which would bog down network
    traffic with individual network calls for each and every
    operation. CocoBase is designed for Enterprise systems,
    but the JDO specification would break down in a distributed
    environment very quickly based on my review of it. But if
    we had been asked, we would have stated it months ago...
    This isn't the first time I've heard this argument, and
    perhaps it holds water for other vendors, but not for
    CocoBase...

    Craig sez:
    "If you assume that the object graphs are Serializable,
    you are artificially constraining the problem to those Java
    classes that either themselves implement the serializable
    interface methods, or can use default serialization. "

    THOUGHT Response:
    Oh please. First of all typically working in a distributed
    environment the classes are already serializable. Any
    junior Java programmer knows this..

    And the default serialization doesn't do O/R mapping,
    otherwise developers wouldn't need O/R mapping tools
    would they?

    It's becoming increasingly clear to me that while the
    JDO specification may have strong ODBMS underpinnings, it
    still needs significant work both politically and
    technologically before it will actually be useful for O/R.

    The belief stated in the response that serialization is
    somehow O/R mapping is kind of disturbing in its lack of
    understanding of this problem space and explains a lot...

    Craig sez:
    "But JDO allows transparently storing instances of classes
    that do not support serialization, and for classes that are
    serializable further allows identifying fields in the
    object model as being transient for serialization
    purposes but persistent for storage in the database.
    This solves the issue of serializing the entire database,
    if you have a natural Object Model. "

    THOUGHT Response:
    Oh come on that's the most artificial argument that I've
    ever heard. To make a transient field persistent is a
    strage idea. They contradict each other. If it's transient
    it should NEVER be persistent. As for serializing the
    entire database, perhaps that's how ODBMSs would write the
    application, but it's inconsistent with both how the real
    world works, or how CocoBase works. This response seems
    desperate to describe both artificial and irrelevant issues
    that don't even relate to REAL distributed or relational/
    object programming... The reasoning in here isn't even
    relevant to real problems...

    (continue on part2...)
  7. (part 2 continue... read part1 first)

    Craig sez:
    "The complexity of enhancing a Java .class file is on the
    order of compiling the file. There's no extra code for the
    developer to manage; it's just an extra step during either
    development or deployment (depending on the tool). And if
    you enhance using one tool, you are done. The classes can
    be used with any JDO vendor's implementation. "

    THOUGHT Response:
    Actually this means there'll be two versions of the java
    classes. This is a maintenance issue, and it's intrusive
    and limits JDOs usefulness. If a developer wishes to use
    a mix mode app where EJBs are to be used with something
    like a 'state' object and the client app or session bean
    also needs to use its persistence to another source, the
    transactional and context conflicts that could occur
    are mind boggling. The JDO 'transparence' doesn't give
    enough control the developer and therefore constrains them.

    That's a nice thought that customers will be able to
    use any vendor's implementation. Is that kind of like the
    ability to use an EJB bean with any vendor that the EJB
    spec also requires? There's the specification and then
    there's the reality. There are a lot of things that JDO
    doesn't yet address, so vendors will have to extend their
    products to compensate for this. So while they may work
    to pass your compliance tests, good luck to customers who
    actually have to port a real application!

    With JDO in its current state, based on what I've seen,
    there's no way that a vendor could implement 'real' O/R
    mapping without making extensions... Heck even the open
    source JDO vendors have backed away from using the current JDO spec and only ODBMS vendors actually support it...

    The statement that this is 'no real effort' is especially
    ridiculous since CocoBase a real product available today
    can already do that WITHOUT bytecode manipulation. In
    otherwords we have a spec that's promising in the future
    what vendors already ship today with less intrusion. We
    have also had customers who looked at the initial JDO
    implementations and abandoned it because they couldn't even
    debug their own apps after bytecode instrumentation! That
    hardly sounds more manageable or unproprietary to me...
    If a processor modifies bytecode with proprietary
    instrumentation that prevents proper application debugging,
    then that's a really bad design in my opinion.

    Craig sez:
    "Besides yourselves, can you be more specific?
    Highly-placed sources within the industry, speaking on
    deep background, perhaps? "

    THOUGHT Response:
    How about customers. You know - people who actually build
    applications - and not just standards... How many customers
    have implemented enterprise applications on JDO? How many
    of the architects of JDO actually built O/R mapping tools
    that are used by the industry? How many times did you try
    to consult real O/R product vendors when constructing this
    standard? How many customers did you actually ask whether
    they wanted object model intrusion or not - or did you just
    tell them that it was good for them and you knew best...

    Since we weren't consulted, and noone in the JDO group
    can be bothered to consult vendors who actually have to
    deliver real products - it's hard to see how we could
    possibly adopt a specification built in such void of input.
    Especially in light of the uninformed critical postings
    such as this one from you.

    Craig sez:
    "It's unfortunate that in order to promote its Cocobase
    product, THOUGHT felt it necessary to make inaccurate
    statements about competitive technology. "

    THOUGHT Response:
    This is what psychologists call 'projection'. Actually if
    JDO is what you say it is, why would it be competitive
    technology? Unless you're trying revive some dead product
    for JDO??? My understanding was that JDO was an open
    specification? Or is this another typical 'reference
    product' that will simply die from a lack of care and
    feeding? If so is it a technology or a specification that
    you wish us to adopt? Are you finally interested in our
    feedback? And if so why haven't you worked with
    us to take our feedback to the specification? You may have
    grand visions of JDO, but at this point it's only a
    slightly modified ODMG specification that's about 10 years
    old and about 10 years out of date for Java. If you want
    us to support it, it needs to advance a decade, and you
    need to take our feedback seriously instead of criticizing
    it. We're the vendor with the market accepted O/R tool,
    not you. The reason we're successful is that we listen
    to customers and provide real value.

    Being combative to the very vendors that you need for your
    new specification to succeed, and not worrying about what
    customers actually want will cause your specification to
    flop like those before it. When you stop talking and
    start listening to the marketplace then maybe JDO will
    change to reflect those values...

    It may suprise you that we actually wanted to support JDO
    despite the fact that you never involved us in the
    creation of the specification - a HUGE oversight on your part in my opinion!

    We actually took the time to investigate the specification
    and found that it would destroy the performance of any
    application that an Enterprise customer might wish to
    build, and that it was neither transparent nor non-intrusive
    and that it was completely devoid of any relationship to
    O/R mapping... It's an Object Database specification, and
    while ODBMS vendors that don't already have a query language
    such as SQL might like it, it's way to much overhead and
    too poorly architected for enterprise development. The
    double parsing of OQL and SQL is a horrible design for
    relational O/R mapping, and will seriously compromise the
    performance of applications!

    Your arguments for why it has to be architected this way are
    completely flawed and poorly argued. We prove the contrary
    and demonstrate that in fact you can develop TRUE
    transparent persistence with no bytecode mangling or
    class hierarchy intrusion, and that it can be fast and
    vendor neutral!

    Next time you wish to promote a specification in an
    established marketplace you might want to consult the
    companies that actually deliver products in it. We have
    a much broader understanding of the marketplace than you
    could possibly have, after all we are the market leader
    in distributed O/R mapping for the Enterprise.

    For you to so arrogantly discount our expert knowledge is
    horribly unprofessional in my opinion.

    We'll be happy to give you our feedback on JDO 2.0 if it
    ever is made, but JDO 1.0 is currently unusable for our
    customer base, and contrary to your arguments it is not
    a 'competing' technology any more than EJB is, but it is
    an ill conceived specification for the purposes of O/R
    mapping - and as such I can't endorse using it for that
    task in good conscience!

    This assessment of our stance is seriously deluded and
    needs a major reality check! We're responding to customer
    demands as any good business does, and honestly the market
    doesn't seem to care about JDO, but it does care about high
    performance and non-intrusive O/R mapping - something we
    deliver today!

    This flame war should have been carried out in private and
    not in such a well respected forum. Please refrain from
    making these public hit pieces on a forum such as this
    to promote your pet projects unless you do better research.
    This doesn't reflect well on you, Java or Sun to be making
    these kind of snipes at a partner of Sun's and a longterm
    friend of Java. It should be beneath you, and I'm shocked
    at your desperation at making such a stab at our products.
    If you want JDO to succeed, work with us. It's the only
    professional thing to do... We've always been a huge
    supporter of standards, and this stab is both inappropriate
    and petty... We'll be happy to support JDO if it evolves
    into a useful specification for O/R mapping. Until then
    we leave it to the ODBMS vendors where it is MUCH more
    appropriate.

    Ward Mullins
    CTO
    THOUGHT Inc.
  8. Ward,

    <laugh/> Dude. Chill.

    We just got done with an eval of CocoBase, and we decided that, *regardless* of the underlying O/R tool, the Swing GUI that came with it was *way* too beta to foist off on our less experience developers. This was coupled with the fact that when we unjared the product, the file system layout was *absurd*, and obviously full of crappy legacy decisions. (What's with update406.zip in the root dir? And why do you guys only buy half-way into ant, instead of actually using it in a rational manner?)

    But what really stopped us from using it was the attitude of our sales guy. He absolutely blew his stack when we brought these problems up. It was comical, being yelled at and insulted on a sales call. The only explaination we could fathom was that there was a culture problem at the company, which must have been coming from up high.

    You, my friend, just proved that.

    <wink/>

    Cheers,
    Carson

    P.S. Take a peek at http://jakarta.apache.org/ojb/
  9. Hello Carson!

    i can 100% agree to your posting!
    ..... but there ist on BIG problem:

    what persistence layer (for production) to use?!?!
    - EJB 2.0
    - OJB from apache is not yet finished :-(
    - 'home grown' mapping tool (but what about clustering, ...)
    - JDO implementation (which one)?
    - ????????

    can you give any hints?
    what do you use (and why)?
    how to be database independent?

    greetings,
    blip
  10. Is this an advancement of your coconavigate system.
  11. Absolutely it is Sanjay. It's a new Instance based version
    that's better suited to working in a fragmented and
    threaded server environment.

    It's also now integrated to work with UML/XMI so the process
    of defining the transparent persistence just became a cake
    walk! In fact if you already have it defined, it's about
    a 30 second process to import your model into CocoBase and
    even to generate DDL for your database if you want...

    Ward Mullins
    CTO
    THOUGHT Inc.
  12. How would you two compare Castor's JDO vs. Sun's JDO and O/R tools such as Cocobase? Castor's JDO is a different implementation than Sun's JDO. Not sure how many companies out there are using it, but it has been around the block for almost two years.

  13. CocoBase is truly non-invasive. Any JDO solution (Castor
    or Sun's) is inherently invasive because of the JDO spec.
    CocoBase believes transparent persistence means that the
    object model is unware of its own persistence (hence the
    term transparent), but JDO requires that the Object be
    modified either by coding or bytecode mutilation to meet
    this requirement. It's unnecessary, invasive and ill
    informed...

    Also CocoBase is a mature product that focuses on
    portability, performance, integrations and all of the of
    the other things that customers need in a product. Both
    Sun's JDO and Castor are basically research products at
    this point. One customer recently reported to us that
    their Overhead with Castor ran 100 times slower than their
    hand coded jdbc code. Compare that with CocoBase which
    if properly configured has only about a 1 to 2% overhead
    compared to hand coded JDBC...

    That has everything to do with the fact that the product
    was crafted based on the requirements, architecture and
    features and limitations of the Java language and JDBC.
    The product reflects good engineering practices and a
    desire to have an infrastructure that runs as good or better
    than anything the developer would hand code. The CocoBase
    Enterprise O/R product for Java is almost 5 years old, and
    it's difficult to reproduce that mature of a technology in
    a basement in a few months - even from the best engineers...

    Just my $.02

    Ward Mullins
    THOUGHT Inc.
    http://www.thoughtinc.com
  14. Cocobase uses Serialisation?[ Go to top ]

    Ward,

    I just found this article with the help of the new JDOCentral site. If you are still reading along:
    If Cocobase uses serialisation, how does your engine
    handle modifications to class files?

    I like your point on non-invasive persistence. We
    are going the same way but our engine uses reflection
    to store objects. Accordingly you may modify your
    classes as you wish and our engine will always hold a
    superset of all stored versions of classes. I don't see
    how this could be possible with serialisation in a
    living and moving developing application.

    Having read the complete thread, I do think it would
    be more appropriate to mail with Craig in a more polite
    tone. I do think it's great that Sun cares about
    object-relational mapping. All the companies that want
    to drag the industry away from using pure SQL
    are allies.

    Kind regards,
    Carl
    --
    Carl Rosenberger
    db4o - database for objects
    http://www.db4o.com
  15. This is a general question with J2EE that luckily we don't
    have to deal with ourselves, as it's an issue for the app
    server itself. Since we're not supplying the serialization
    and instead the app server and jvms are doing that for us,
    we assume (reasonably so), that this will be correct.

    You're correct that app servers & classpaths can get out of
    sync, but that's true anytime j2ee components are used,
    whether it's an EJB's remote interfaces, or an object
    persisted by the session bean.

    Our new release due out later this week further enforces
    the concept of a 'dynamic facade', where a developer can
    move from a 2-tier to a 3-tier Session based application
    at runtime! No need for an application recompile - pretty
    nifty stuff!

    Ward Mullins
    CTO
    THOUGHT Inc.
    http://www.thoughtinc.com