> > > - 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. > > I believe this is incorrect, Commit Option A means that ejbLoad will not > get called. It means that the container has EXCLUSIVE access to the > database, so only ejbStores should happen. As the other guy reported in > the bug report, this means that the data object never gets nulled. > > See section 10.9.5, figure 29 of the EJB2.0 spec (it clearly states that > ejbLoad is not called with commit option A) >
Ok, excelent ! So the XDtComment in ejbLoad is not a bug. And we need to refresh the state in getData(). I never saw that. Remember, I don't use DO currently and did the VO stuff as a Theory : I never used them, I really appreciate your clever feedback :) To summarize: We declare a Vo as an entity attribute with null value In getData we instantiate it if its null Then we set all the atrributes in it. We never reset it to null. In the case of one transaction and multiple calls we will get the same instance In the case of multiple calls in different transaction we may (if using MultiInstanceInterceptor) receive different instances but we don't care; or we will get the same instance (in classic InstanceInterceptor) but we should be aware than we can not benefit anything from that. We need a Version Number Pattern to solve the stale/user think time problem. We already have it for DO, we need it for VO. In CMP2, because the setter on an entity bean is abstract, we can not update the version number in all attributes setter but only on the setVO() method of the entity bean. So I guess there is no way to avoid a programmer to declare one of the attribute setter in the local interface and call it to update the value, the version will not be updated; then when a second setter (now on the VO) comes, itwill overwrite its change. So we need to provide a checkAndUpdateStatus() method on the entity bean that the client (session facade) MUST call to prevent the problem. Agree? 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
