Hi Vincent, On Wed, 15 May 2002, Vincent Harcq wrote:
> > > > - 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. <-- HERE > We never reset it to null. Yes, this is what I believe should happen. Just to clarify, the "<-- HERE" line needs to happen on *every* getData/VO > > 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? > Hmm, I don't quite understand the last sentence. Can you explain who has to call checkAndUpdateStatus() (do you mean anyone that calls a local/remote interface set() method must call this first?? Ouch!). I can't really see any nice way of getting around abstract setters (and for collections, getters!) in CMP2.0, without getting down and dirty writing custom interceptors in JBoss. This is why we are using course grained software locks (see previous email). Craig _______________________________________________________________ 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
