Hi Chris,
>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?
Absolutely, I take a few hashtable lookups anytime over database access or
some other complicated, bean-based scheme to share data. Just for the
record, I never mentioned fine grained components. Instead, I have been
advocating balanced designs.
>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.
Hey, it is a matter of taste. Face it, once your project goes beyond the
trivial prototype phase, it will need to do more bookkeeping. There is no
way around that. And the server certainly is better equipped to do it in a
generic fashion than your beans are. After all, isn't GC one of the main
reasons why a lot of us don't use C++ anymore and favor Java? GC is nothing
more than bookkeeping in my book :-).
>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?
It's not the content, it's the size :-) Set the size of your server's
virtual memory page size to 10MB and you will see what I am talking about.
>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.
I certainly hope you don't simply take your prospect's db and map tables
into beans on a one-to-one basis :-) On the other hand, if you have a well
designed model with 500-600 components, I absolutely prefer to create the
same number of beans and would be quite upset if you forced me to squeeze
unrelated functionality together in the name of "performance".
Regards,
Imre Kifor
Valto Systems
>> -----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".
>
>
===========================================================================
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".
