Hi, Very important indeed. I'll explain how I understand it, maybe I am wrong, correct me then. Please provide the container with wich you are working. I am with JBoss.
> 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. ejbLoad must be called when the container decides to refresh the entit bean state for any reasons. So with DO, ejbLoad sets it to null prior to calling getData(). With commit-option A, if the container decides to not ejbLoad() it is because the state of the entity has not changed, so why "kill" the DO, it has still the correct value. To summarize a DO can only be dirty if the entity bean state change, and in this case ejbLoad() must be called, so the Do is reset to null so no problems. > > - 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) I agree maybe the object uniqueness is maybe not completely Ok or maybe should I say "respect Pure Object Oriented way of doing". But... I don't believe that in the case of 2 clients getting a instance of A Value Object MUST absolutely have the same Instance of it. The client do not care about that but only about the VO.getPrimaryKey().equals() method when doing "isDentical" between VO. We should also talk a bit about the MultiInstance approach of EJB containers where for a specific PK, multiple instances of an EJB can cohabit in the server. In this case it is simply impossible to give the same instance of the VO to the 2 clients. > > > 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. > With VO we introduce (Marcus could also talk about that) a "volatile" attribute that do what DO do, this is when its value is set to "true" (which is the default) resetting the entity cache of the VO to null in ejbLoad(). So every clients will get its own VO instance. Setting volatile to "false" (I think this is the (wrong) default on XDoclet 1.1.2) will not null the VO on ejbLoad, instead the getVO() will refresh the entity instance's cache version of it. I would not recommend using volatile="false", it will not provide a big amount fo gain (99% of the time an entity is stuck in the JDBC calls). BTW, when writing this email I checked the templates files and ejbLoad does NOT refresh the VO, I was pretty sure it was OK there, I surely mess it up at some point, Marcus can you have a look ? There is a <XDtComment:comment> that avoid the entity-value-clean.j to be processed. I don't have CVS access right now, I will see that tonight... Regards, Vincent. _______________________________________________________________ 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
