1.  What is the performance loss, if any, when using JDO?

JDO is an abstraction layer (of sorts) that sits above JDBC. We all know
that abstraction layers typically add overhead to a problem and thus
have the potential to impact performance. Our experience has been that
in most situations JDO has proven to be now slower than, and oftentimes
faster than, a hand coded JDBC implementation. The reason for this is
that it is far easier for the typical developer (who is not expert in
JDBC and RDBMS) to write good, efficient JDO than it is for that same
developer to write good, efficient JDBC. An analogy that I used in the
presentation was the war of words that occurred between the "C"
programmers and the "assembler" programmers back in the early-to-mid
80s. Additionally, just as "C" is more portable than "assembler", JDO is
more portable than JDBC.

2.  What is the query language and capability in Versant\'s OODB?

Versant's server supports query capabilities similar to those found in a
relational database. This query language is leveraged directly from
C/C++ and Versant's original Java interface, JVI. Of more import to the
XMDR group, however, is Versant's JDO interface. The current release of
Versant's OODB (called VDS) supports a subset of the capabilities of the
JDO Query Language (JDOQL) required by the JDO 2.0 specification.

> However, with release 7 of VDS (which will enter beta in February),
> significant enhancements to the query engine have been made that
> "close the gaps" in terms of query functionality that will enable
> Versant's JDO interface to be fully JDO 2.0 compliant, both when
> running against a relational database and against VDS.

3.  What are the tradeoffs when \"tuning\" JDO for Oracle, or other
    DBs??

> The tradeoffs of tuning a JDO-based application for a specific
> database (i.e. Oracle) are the same as for tuning a hand-coded JDBC
> implementation for a specific database. Some additional performance
> may be found in the process, but it is likely that future flexibility
> may be impacted. By "flexibility", I am referring both to the ability
> to deploy against a different database (i.e. Sybase or VDS) and to the
> ability to evolve the application itself.

4.  What is the impact, if any, of vendor-specific extensions to JDO?

The impact is fairly minimal. The JDO specification recognizes that it
can't address all possible use cases or idiosyncrasies of
implementation. It consequently allowed for the possibility that a JDO
vendor might want to "extend" the meta-data language with its own
"special" capabilities. The JDO specification allows for this and
provides a very specific syntax for doing so. It also stipulates that
unrecognized extensions be ignored so that, while some functionality may
be lost, the meta-data file itself will remain portable across JDO
vendor implementations. The user, of course, has the option of finding a
way to "crack the nut" of the now-mission functionality with the new JDO
implementation (perhaps again using vendor-specific extensions).

5.  Is Ontology fundamentally the \'same\' as OO?

Ontology is not fundamentally the "same" as OO, but they are very
similar in nature. They both have the notion of a data structure that is
a combination of "data" plus "behavior." They are so similar in nature
that ontologies are almost always implemented using object-oriented
concepts and languages. The fact that they are very closely related is
underscored by the fact that the Object Management Group (OMG) is
working defining and standardizing how the software development world
specifies an ontology (http://ontology.omg.org).

6.  What is the cache (in memory) capacity for Versant?

For JDO (on the client side of things), the limits are not imposed by
Versant, but rather are a function of the amount of heap that the
operating system and the JVM in question will support.

> Versant's server cache is placed in shared memory and thus the maximum
> cache size is largely dependent on OS limitations associated with
> shared memory configuration. At present the Versant server is
> configured to manage a cache consisting of up to 2048 shared memory
> segments. The largest shared memory segment size allowed varies by OS.
> For example, on Solaris, the largest size allowed is 64 MB. Doing the
> math, that translates into a maximum server cache size of 128 GB on
> Solaris.
>
> On the other hand, SGI's Altix platform (running Linux) supports a
> maximum shared memory segment size of 1 GB. Doing the math for this
> platform indicates that a server-side cache of 2 TB is possible,
> although to date we have not had the requirement (or in-house ability)
> to test caches of this size. We are, however, pretty confident that
> this can be achieved and will pursue this more aggressively if
> required by a customer.

7.  Please provide pointers to JDOQL Versant extensions

With the current release of Versant Open Access JDO, there are some
Versant-specific extensions related to JDO (and JDOQL) 2.0 functionality
as "preview features." According to Versant's engineering group, VOA
should have no vendor-specific extensions associated with JDOQL once the
JDO 2.0 is finalized and approved.

8.  What kind of regex extensions can we get on the server? And not on
    server?

On the server, VDS supports "\*" (match any substring), "?" (match any
single character, and "\[x-y\]" (match a range of characters). Once a
subset of data has been returned to the client based on these fairly
common capabilities, there is no Versant-imposed limitation as to what
sort of pattern matching client-side methods may support.

9.  Besides inheritance hierarchies what are the limitations on schema
    evolution? What things can we do?

> As it turns out, I misspoke a little at the presentation. While it is
> true that that "inheritance limitation" does exist for C++ and JVI, my
> research with Versant's engineering group indicates that this same
> limitation does not exist with VOA JDO. The documentation states that
> the following schema evolution operations are supported:

-   Addition of an attribute to a class and all subclasses.

-   Removal of an attribute from a class and all subclasses.

-   Changing the field type of an attribute in a class.

-   Addition of a subclass to a class.

-   Addition of a superclass to an inheritance tree.

-   Removal of a superclass from an inheritance tree.

> I can't think of anything that isn't covered by the above and I was
> unable to find anyone who could point to a specific schema evolution
> use case that would not be supported.

10. Does Versant have a standard way of persisting handles on a
    database?

I am still not entirely clear on what is being asked here. I believe
that you are referring to the notion of location of being able to locate
an object in a Versant database without knowing specifically which
database it resides in. That functionality is not currently available
with JDO, but will be available in a future release and will be
transparent to the user. The problem is solved the "Versant way" (we've
been doing this for years for C++ and JVI), and not via any "standard"
mechanism. On the other hand, I am also not aware of any "standard" way
to solve this problem.

11. Does Versant support the concept of "transitive closure"?

> Versant has supported the concept of "transitive closure" for C++ and
> JVI for years. It turns out, however, that JDO itself doesn't really
> have this notion. Instead, you use the concept of cascaded fetch
> groups.