OK, sounds good, I'm not sure how useful the checkAndUpdateStatus would
end up being, I'd have to think about it more. Got any URL's for more
details of this pattern?
BTW, we have also patched our xdoclet to hava dirty checking on the
dataobjects, as we pass across large graphs of objects where only one may
be dirty. This saves possibly hundreds of setData()s. It's a pretty
simple patch, but I thought you might be interested. Basically we add
these methods to the EJBData.java API
makeClean()
makeDirty()
isDirty()
and call makeClean() within getData(), and call makeDirty from all the
EJDData.set() methods. With our course grained locks, this works very
well.
Thanks Vincent and the rest of the XDoclet team. I hope to get more
involved with XDoclet development when our current deadline has been met.
Regards,
Craig O'Shannessy
On Thu, 16 May 2002, Vincent Harcq wrote:
> > > 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
>
> Yes.
>
> >
> > >
> > > 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!).
>
> Yes that is what I mean, when people calls setter on entity local interface,
> XDoclet can not help to solve the stale problem.
> So Either you go via Value Objects and there we can help, either you don't
> (session facade decompress the VO and set attribute per attribute on the
> entity) Then this session facade must call a method checkAndUpdateStatus on
> the entity bean to assure no stale data will be saved. This is how Floyd
> describes the use of DTO in his book EJB Design Patterns. His concerns is
> that the DTO should not be "entity linked" to decouple the client layer from
> the domain layer, which is fine in big project but then "of course" xdoclet
> can not help because the entity is not aware of DTO. Some other entity
> engine is better than (or a complement to) xdoclet when people wants to do
> that.
> Let's forget that ;)
>
> >
> > 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
> >
>
> 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
