><[EMAIL PROTECTED]> wrote:
>>Glenn wrote:
>>
>>I don't think [O-R mapping] would not be any easier using
>>fine-grained entity beans.
>
>Please explain.
>
I mean, similar queries can be used to access relational databases from
either many fine grained deployed components (entity beans) or from the
same number of fine grained objects embedded in a single entity bean.
(Assuming that bean managed persistance is used for either case.)
>>Coarse grained object graphs allow us more control over how>we query our
>>RDBMS.
>
>Please explain.
It may be more efficient to obtain many rows of many related tables using a
single query or view and build an object graph from the results of
this query. As opposed to loading each row into its own bean using its
own load method, which could prove to be less efficient.
Brian writes:
>I guess that means fine-grained transactions won't perform well with
>large graphs of mostly unmodified objects.
I acknowledge that this is certainly a serious consideration. I would like
to provide a bit of background before I address this concern. One of
the business requirements of the application we are developing, is to allow
the user to modify a screen worth of information, then save it all at once
within a single transaction context. This screen may consist of multi-level
data, and therefore is well suited to coarse grained object graphs.
As you can imagine, performing many remote calls to update fine-grained
components could prove to be unbearable over a slow modem connection.
So we have added the concept of isModified to all of our objects so that
only changed objects are updated. However all object are currently
serialized over network, whether they need to be or not. (undesirable,
I admit) We are deferring the analysis of how we could avoid the transmission of
unchanged objects, short of writing our own serialization.
Although what we are doing it may take a little longer in the worst case,
the user's perception of the update time will be fairly consistent with
load times. I have found that, with software, perception is almost always
more important then reality.
-Glenn.
===========================================================================
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".
