Hi, > > Jboss (hey that's the only where we can see the internals) is not > far > > from that, > > You can avoid n+1 problem with read-ahead > > You can cache entity bean with commit-option A > > But it will hit the database for the query > > And I still need to transform my collection of entity beans to a > > collection of data-object to send to the client. If I early-load > this > > data-object inside the entity bean I can avoid the overhead, so > come to > > something as fast as direct sql. > > but you still then lock the beans... am I being overly worried about > this > you think? > I was looking for a way to do a pure query of the "last > known > state" and have that provided by the container... what you have below > looks good though...
Locking what ? I create my dataobject at ejbLoad() time I reset it at any setter method (like rickard's data-object really) I get it via a getData() method that is transaction Supports called by a SessionBean that have a transaction Supports. I do an ejbAll on startup of Jboss, have everything is memory. There are 1 write for 100 read in most applications There may be contention on the container level but no "locking", these contention that may exists in actual ejb container will disappear with the time... I may be completely drunk in what I am saying :) > > > I Agree completely. > > I have done that :-) > > thankyou! I will spend more time looking at it at some stage... > going > into purist mode though - this ought to be done by the container > yes? back into real world mode, who cares who does it as long as you > dont > _write_ the code yourself, yeah? (o: absolutely, Well most if not all TSS patterns could be implemented using xdoclet :o) > > [code snipped] > > > > my real problem though is what to do with relationships... > > > should I try to be super clever and do the sql for the joins, > > > or should I just wear the performance hit of having to do > > > multiple queries? > > > > I don't have that :( > > hehe... any thoughts? Well my mail was up and down, the reponse was just below : sql finders sucks balls ! In fact I don't like the first approach ans use it only as backup to something I would like to work but do not work yet. > > > Imnsho telling that we need an sql remapping for finder method is > the > > same as telling that entity bean is bullshit. > > but entity bean isn't everything... if I want to display the > catalogue of > products, I dont want to have to lock every item in the catalogue to > extract data... Where is there a locking ? That something I read here and there but still can not understand. If I preload the data as entity beans, suppose infinite memory, accessed without transaction context, where a lock must happen ? to do what ? > you have done it as a home interface method right? Yes > so > have I, but the code is in the container. I agree that I should be > able > to re-use the data in the jboss cache, but dont know enough to do it, > so > went the re-use of sql approach instead... I did not want to reuse JBoss cache but JBoss CMP command (finders, update, ...) to create any data-objects (remember I hate them but I need thousands of them for my clients ;) ) that have a mapping to one/multiple table. A Castor in fact. Or Cocobase or ... But STANDARD J2ee not a think I pay 10.000 $ and is obsolete next year :) Castor is may be the best solution to handle relationships no ? Use the jboss-cache, ... mmm ... have to think about that > > > With a good container, finder methods should be as fast as writing > sql > > by hand > > Does entity developement still need sql ? Yes > > Will it make entity bean survive ? No > > The developer should forget that a database is behind, should even > not > > know that a database is behind > > The deployer have db knowledge and do the sql query with the info > the > > developer gives him. > > agree agree agree agree > > > > personally I think something like this would go a long way > > > towards removing criticism of entity beans... I suppose the > > > reason I'm writing this here is that you guys seem to have > > > different view of the whole data object thing, so I'm > > > wondering if some of that might show me a better option. > > > > I tried to look at how externalize Jboss JAWS on my spare time to > be > > able to reuse it outside EJB. > > If days could have 48 hours... > > hehe... > > > I think again MVCSoft/Daniel O'Connor (respect!) is going this way > > must look... > > > Another way could be JDO as persitance maneger (inside ejb > container) > > yes... when its finally available... I mean, _properly_ available... Why do say that ? I think a RC is available, Can you share your thoughts about JDO implementation. I personnaly avoided Castor because it is not ".standard" > > anyway, thanks for the feedback and code - much appreciated. Thanks for your patience :) > > cheers, and g'night > dim > cheers, Vincent. __________________________________________________ Do You Yahoo!? Buy the perfect holiday gifts at Yahoo! Shopping. http://shopping.yahoo.com _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
