Closed & Fixed Issues

Printer-friendly version


Release Notes



Assist only shows the first element of an array object when viewed through the Object window.

Assist Plug-in


Customers using R10.2 may see null/incorrect objects/data if object was in a checkpointed transaction due to object being incorrectly marked as fetched.



If a container fills up when writing objects, and the cluster strategy allows creating a new container if needed, implicit moving of the last object from the full container to the new container can result in a NullPointerException.



If a container fills up when writing objects with arrays, and the cluster strategy allows creating a new container if needed, implicit moving of the last object from the full container to the new container can result in a crash.



Due to over aggressive cache cleanup during commit, users may see longer than expected commit times. This time will vary depending on the number of Objectivity/Java objects the customer has used (and is therefore in cache).

Java Performance


While stress testing it has occasionally been noticed that the new multithreaded oolockserver becomes unresponsive and unreachable by the client:

** System Error #3049: Error communicating with Lock Server on host
"host": A connection with Lock Server on host "host"
timed out

Lockserver (oolockserver, ools, lm)


When creating a container, if a container ID number is explicitly
provided and that number is widely separated from any existing
containers (by an order of a few thousand), the creation may fail with
the following misleading message:
** Error #4563: ooContObj::operator new: Storage Manager: Creating an
already existing Container #x-xxxx (100350)



Attempting to create a container and call ooRefHandle(ooContObj)::exist(ooMode openMode) n*255 times on that container in the same transaction, where n is an integer greater than zero and openMode equals ooRead or ooUpdate, results in the container closing prematurely upon commit. The container will be inaccessible, as can be seen from oocheck reporting that the container cannot be opened. Furthermore, reusing the same ooSession object in a subsequent update transaction can result in ooSession::commit: Storage Manager: Internal assertion failure: osmControl.cxx:577: fileDesc->closest->controller (0) upon commit.



oorestore of a backup of a database may sometimes fail with an error like this, even though oobackup completed with no errors.

** Error #4400: Storage Manager: FD updateTS 1 is smaller than OC #87-46
updateTS 742 (100655)
This indicates a certain discrepancy in the page map of the database.
oobackup and oorestore need to issue a warning when they encounter the timestamp discrepancy in the pagemap, and continue running.

Tools: oobackup / oorestore


Although this error is seen only in debug builds, the underlying problem results in ootidy not properly setting up the container catalog, resulting in the loss of containers. Related to the bug in OBJY-18698. Affects only new catalogs(post R9.0)

Tools: ootidy, Objectivity/DB


If more than a thousand containers have been deleted from a database such that there is a large range of contiguous container numbers which are no longer in use, then after "ootidy" is applied to that database, a second use of "ootidy" or use of some other tools such as "oobackup" may lose the containers which have numbers above that gap.

Tools: ootidy, oobackup, oorestore, Objectivity/DB


ooupgrade has been observed to fail with the following error:
** Error #15436: ooschemaupgrade: Could not change the inverse of
association owner from To-Many to To-One
** Error: Unknown exception in ooupgrade main

Tools: ooupgrade

Wednesday, March 7, 2012