[ http://www.jpox.org/servlet/jira/browse/DBFO-8?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel#action_14025 ]=20
Xu=C3=A2n Baldauf commented on DBFO-8:
---------------------------------
Hi Andy.
Thanks for you comments. Please let me reply and explain shortly.
(1) Agreed. I'll read the coding conventions. (I haven't done that that up=
to now, I want to get it running in the first place)
(2) Agreed.
(3) Agreed. These changes were for different reasons not mentioned before (=
they just showed up because the patch represented my whole diff against CVS=
HEAD). One reason is that "jdo2-api" is now final in version 2.0, not in a=
SNAPSHOT stage anymore. Another reason is that JPOX currently does not com=
pile under Java 1.6.
(4) Agreed on commenting and on moving public methods to the StateManager i=
nterface instead of making JDOStateManagerImpl public (It was just a tempor=
ary hack resulting of debugging). "HollowPreConstructed" means that the obj=
ect is pre-constructed and should be used as such, that means that there is=
no need to construct is using a Class object in the first place. I used a =
slightly different method name to reflect the difference in the semantics, =
all other initialiseForHollow() methods construct the object by using a Cla=
ss object.
(5) The StoreManager.notifyMainMemoryCopyIsInvalid() tells the store manage=
r that the main memory copy of the PC in question is invalid. Typically, th=
ere may be 2 copies of a PC, one in the Java heap (main memory), one in th=
e database. The question is, which of these copies is "authorative" (i.e. m=
ore current). Sometimes, the copy in the main memory is more current (i.e. =
when the PC is in state PERSISTENT_DIRTY). Sometimes, the copy in the main =
memory is just plainly wrong (i.e. when the PC is in state HOLLOW), but the=
copy in the database is authorative. Sometimes, both copies may match (i.e=
. in some cases of the state PERSISTEN_CLEAN). The implicit nature of DB4O =
in particular (and object databases in general) may make DB4O copy data fro=
m main memory to the database when in fact it should not (for example, when=
the PC is in HOLLOW state and the main memory contents are plainly wrong).=
DB4O needs to be told about that to not accidentially do these types of wr=
ong copies. Other databases (including JDBC databases) do not have that not=
ion of impliciticy, thus it makes no sense for RDBMS backends.
(6) Good idea. I did not intend to keep the diagnostics to the final versio=
n of the patch, but I can consider enabling that (if there is no other easy=
way to instruct DB4O to generate these diagnostic messages).
(7.0) The FetchSecondClassMutableFieldValuesAsWellFieldManager does pretty =
much what its name tells: it fetches all values (i.e. objects) which are po=
inted to by second-class fields of the PC. Basically, it fetches all second=
-class-objects of a given parent. While I do not really insist on certain n=
ames, I do not see what is wrong with it in this case. It is just unusual l=
ong. Is it too long? (I prefer explaining names over abbreviations).=20
(7.1) The reason to make this class a local inner class is guided by the sa=
me reason to have local inner classes at all in Java: To write the code the=
re, where it is needed, and this class is only needed by one method. Furthe=
rmore, inner classes are common used an recommended when callbacks are need=
ed (and in this case, FieldManagers are all receiving callbacks by the PC).=
Another reason to have this class as local inner class is that the class d=
epends on the transient ObjectContainer object. Thus, it cannot be made sta=
tic. Thus, it would be kind of cumbersome (and go back to the Java 1.0 lang=
uage features) to move that local inner class to another external class, ev=
en in a different packare. One result would be that the ObjectContainer obj=
ect (which is very private to that method) and conceptually should not leav=
e the method actually would go through public constructors. This is not goo=
d OO-encapsulation, IMHO. That's why I made that class a local inner class.=
However, if you still want that class to be moved out into another package=
, I can do this.
> JPOX DB4O layer not mature for release
> --------------------------------------
>
> Key: DBFO-8
> URL: http://www.jpox.org/servlet/jira/browse/DBFO-8
> Project: DB4O
> Issue Type: Bug
> Affects Versions: 1.2.0-beta-2
> Environment: Java 1.6.0u1 under Linux x86 32bit
> Reporter: Xu=C3=A2n Baldauf
> Attachments: DB4O_fixes.raw.patch
>
>
> Hi, sorry to do that on you, Andy, but in the current DB4O layer are many=
flaws.
> Among them are:
> (1) Query By Example ("QBE") when retrieving objects. Currently, the JPOX=
DB4O layer takes a hollow PersistenceCapable object and submits that objec=
t to ObjectContainer.get(). What does the JPOX DB4O layer get? Of course, a=
ll objects in the datastore which match that template object. This almost a=
lways fails when two or more objects of the same class are stored in the da=
tabase, as _all_ objects are returned by ObjectContainer.get(). Unforunatel=
y, ObjectContainer.get() is not the "natural" inverse of "ObjectContainer.s=
et()". The correct way to retrieve the content of hollow objects is to use =
ObjectContainer.activate().
> (2) However, to let ObjectContainer.activate() be effective, hollow objec=
ts have to be deactivated when transitioning from some other state to hollo=
w. This does not happen with the current JPOX DB4O layer. (One can try to =
workaround this by using ObjectContainer.ext().refresh()
> (3) ObjectContainer connections are not retained between transactions of =
the same PersistenceManager. Rather than that, ObjectContainers are opened =
and closed with each transaction. This may be bad for performance. But it i=
s worse for identity management. Because the association between an object =
currently in the JVM and its persistent representation in the DB4O database=
is only kept alive as long as the ObjectContainer is not closed. This prac=
tically means that DB4O cannot load contents of objects which were created =
one transaction ago.
> (4) Objects to be loaded may be partially hollow, partially persistent-di=
rty. That means that DB4OManager.fetch() has to honor the fieldNumbers para=
meter. JDO supports finegrained loading and unloading of only some fields o=
f an object. DB4O only supports loading or unloading all fields of an obje=
ct, there is no thing as "partially hollow, partially persistent-dirty" fro=
m what DB4O supports. This has consequences. One consequence is that one ca=
nnot simply load an object from DB4O when only some fields of the current o=
bject are requested and other fields of the current object are dirty (that =
means: they must not be overwritten).
> (5) This also applies the other way around. One cannot simply write an ob=
ject which is "partially hollow, partially persistent-dirty", only because =
it is also dirty. Because then, the data on disk will be overwritten by "nu=
ll" or "0" values from the hollow (that means unloaded) fields of the objec=
t to be written.
> (6) It may also happen that an object, which is persistent-dirty, has a c=
hild-object, which is hollow. When writing the persistent-dirty object to t=
he database, that write is considered an "update", and updates normally do =
not cascade to child-objects. Normally. However, the current DB4OManager.su=
pportClassInDB4O() method may, and in deed does, call objectFld.cascadeOnUp=
date(true), that means it forces cascading updates to child-objects. That m=
eans that updates are also applied on hollow objects, that means that corre=
ct objects on disk are overwritten by "null" or "0" values from the hollow =
objects.
> I have learned about the existence of these bugs the hard way - it took m=
e one frustrating week to find and squash them all.
> Having said that, there is no hurry to fix these problems, because I alre=
ady fixed these problems on my copy of JPOX/Plugins/DB4O and JPOX/Core (som=
e additional methods at JDOStateManagerImpl were needed to make things work=
smoothly). That's why I'm asking for commit rights, so that I can actually=
commit these bug fixes so that nobody suffers from these bugs again|anymor=
e.
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://www.jpox.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|