Hi everyone, I wouldn't normally post something from the bug list to here, but this is a very serious bug, and I know you guys are planning on releasing soon, so I thought I should point it out.
It is fairly well documented in bug # 555350 (not my bug, but I have posted additional comments) Basically both the DataObjects and the new ValueObjects seem to have a serious problem, and I have suggested a work around. Would someone mind checking it out please, I can supply all the patches if people agree with my suggested workaround. https://sourceforge.net/tracker/index.php?func=detail&aid=555350&group_id=31602&atid=402704 Here are my comments on it, as the formatting in the bug report makes it a bit hard to read. Thanks, Craig O'Shannessy ---------------------------- Goals ===== Handle large complex object graphs, with lazy loading, dirty flagging, serialization issues (lazy loading or getValueObject doing "new"s would lead to object duplication). Problems noted -------------- - the current DataObjects will not ever refresh with commit option A because ejbLoad isn't called ever (after the initial load). i.e. they can get VERY dirty. - the new ValueObjects do NOT do null checking, creating new ones each getValueObject() call therefore two line items with the same product on the same order would have two different product value objects with the same primary key. This is bad for clients that need to CHANGE the value objects within a graph of them. (i.e. the two product value objects would have different values) SOLUTION? --------- The third choice (IMHO the best) is to re "set" all the fields of the beans internal dataholder on EVERY call to getData/getValueObject. This avoids the dirtyness of the dataobject problem, and also the duplication possibility of the current ValueObject problem. The server should never hold on to dataobjects BETWEEN TRANSACTIONS (except the "dataholder" inside the beans), because other threads inside the server could call getData on one you are holding. Pass by value (RMI) protects you from this. _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
