Imre, Just to make sure I get it: So you are saying that with an architecture as described below, you are less concerned about the overhead that a component architecture imposes on a fine grained object? It seems to me that if every thing is a component, there is a lot of book keeping the server must do to achieve DGC, JDK 1.2 mechanisms or not. And, I fail to understand why if the sub-objects are part of an entities state graph, the object pooling mechanism couldn't handle dependent objects as well? I recently saw a legacy database design in a prospect of ours where there are 500 to 600 tables in the RDBMS schema. I shudder at the thought of having every one of these as an entity bean. Regards, -Chris. > -----Original Message----- > From: Imre Kifor [SMTP:[EMAIL PROTECTED]] > Sent: Friday, August 27, 1999 10:47 AM > To: [EMAIL PROTECTED] > Subject: 2nd generation entity architecture... was Re: > Dependent objects vs. Fine grained objects as entity beans?, was RE: > design question with entity beans > > >At the risk of giving you the podium, I would like to here more about > >"second generation entity architecture" which IYHO mitigates the concern > of > >fine grained entities being too heavy weight. > > > >Regards, > > > >-Chris. > > > It is well known that CORBA-based or Jdk1.1-based EJB implementations > don't > have adequate support for releasing entity objects (i.e. the remote > interface implementation and *not* the bean instance). Some vendors (see > the > list archives) have implemented smart mechanisms to retire entity objects > after a certain timeout (in a quasi-session object fashion). I call such > mechanisms 1st generation entity architectures. > > Java 2-based EJB servers, however, have platform support to release only > the > entity objects that are not referenced anymore by either local or remote > "clients". An entity architecture that takes advantage of the DGC > facilities > of the platform would fall into the 2nd generation category. > > Why is this important at all? To minimize the number of ejbLoads the > server > needs to perform on behalf of your client. For example, let's assume that > you have a trading, bidding or auctioning application. In general, an > application where a large number of quasi-temporary data is processed and > filtered and a more-or-less constant number of instances are kept around. > And, of course, let's also assume that you decided to model trades, bids > etc. as entity beans since they need to be shared (i.e. referenced later, > reported on, processed at the end of the month for statistics etc.). > > With a 1st generation architecture, the incoming trades, bids will very > quickly fill up the available system tables and the server will start > retiring the older entity objects regardless of whether they are still > referenced or not. A 2nd generation system will be able to release entity > objects more selectively keeping the referenced once alive and most > probably > even active. When your users start to ask for reports, in the second case, > the entity objects (with the highest trade, bid etc) will be around and > ejbLoad will not be mandatory. > > There is a lot more detail, however, I think the above pretty much > describes > what I have in mind when I refer to 2nd generation entity architectures. > > Imre Kifor > Valto Systems > > ========================================================================== > = > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
