Chris,
I get the distinct impression that you are saying "don't worry about these
issues, the OR mapping layer will take care of it...". First, I always start
to worry when I hear the "don't worry..." :-)
Second, my point is that with the right (bean) architecture you can achieve
the same (or better) results while using the pretty much standard and
reasonably well understood EJB framework. This does not mean that OR mapping
is not useful or will not do the right thing when it matures and is
standardized. Nevertheless, as long as there is a "magical" touch to the
various still proprietary OR mapping "layers" (just read your first
comment), I -as an engineer and EJB user- cannot take them seriously to
solve *my* real-world problems.
Of course, I -as an EJB vendor- love the challenge and opportunities that OR
mapping presents and can only say "stay tuned..."
Imre Kifor
Valto Systems
-----Original Message-----
From: Chris Raber <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, September 02, 1999 10:35 AM
Subject: Re: EB granularity was RE: design question with entity beans
>Imre said:
>> -----Original Message-----
>>
>> In my opinion, you are making a strong case *against* using
>> large-granularity beans. Here is why:
>> 1) since you must synchronize with the database at both the beginning and
>> the end of every transaction, at least you should minimize the work this
>> entails. That is difficult with large beans, unless you transfer large
>> blocks of data blindly. Which leads to complicated code, fragile,
>> hard-to-maintain datastructures and cumbersome error handling on the
>> bean's
>> end.
>>
>I disagree. If your OR mapping layer knows what has changed, then only the
>deltas must be flushed at commit time.
>
>> 2) the larger your beans are, the more "server" logic you have to
>> duplicate
>> into them to support selective updates. Note: it is very difficult to do
>> en
>> masse storing of state with JDBC.
>>
>The OR mapping layer needs to have a "unit of work" concept which can track
>the deltas. I agree this would be diffilcult to take on in the application
>layer, but that doesn't necessarily mean it Has to be in the entity bean
>infrastructure of the container. Many OR mapping products support this sort
>of thing. I am not familiar with all of them, but both TopLink and Cocobase
>support such constructs.
>
>I also agree with a point Hal made a while back that this stuff ought to be
>standardized.
>
>> 3) the larger your beans are, the more likely they will be accessed often
>> and, consequently, locked often and for longer periods of time by
>> transactions. This fact single-handedly will eliminate the scalability of
>> your system.
>>
>It is not necessary that the lock applies to the whole bean object graph.
>Again good OR mapping layers allow for locking only what changes, and even
>optimiztic concurrency checking based on stamps or changed value
checking...
>
>> 4) the larger your beans are, the more likely you will lock more database
>> objects (tables, rows etc.) during calls. Excellent way to reduce the
>> scalability of your database.
>>
>Same point as #3?
>
>> 5) it is said frequently on this list that transactions should be short.
>> The
>> shorter your transactions are, the faster your claimed benefits of large
>> beans evaporate.
>>
>Please substantiate this claim. Just because a bean is coarse grained does
>not imply that all of its state must be loaded at the ejbLoad time. Loading
>of sub-objects can be lazy fetching, so if the transaction does not touch a
>sub-object, it need never contribute overhead.
>
>> 6) the larger, more complicated your beans are, the less chances you have
>> to
>> find a CMP implementation to support your scheme. <vendor>Ejipt CMP will
>> let
>> you do it :-)</vendor>
>>
>Given the OR mapping vendors have solved most of these issues previous to
>EJB, and all EJB vendors are either OR mapping vendors themselves, or
>working in close partenership with OR vendors, and reasonable EJB server
>should provide you a solution in this area. If it were me this would be
core
>to my selection criteria.
>
>> 7) and then you should consider the impact of large beans on the
resources
>> of your EJB server (see my virtual memory page size rant in the
archives).
>>
>I still think the oppsosite is true. An entity bean requires more
>infrastructure around it than a regular Java object (e.g. its EJB Objects,
>stubs, skeletons, book keeping by the container...).
>
>> Clearly, I am not convinced about the benefits of large-granularity
beans.
>> I
>> still maintain that you should use the *right* size bean that fits your
>> conceptual model, usage, load and tools. Go figure...
>>
>Concur on "right size". I don't buy broad brush generalizations either. Do
>the design work, think it through... There ain't no silver bullets.
>
>-Chris.
>
>GemStone
>
>===========================================================================
>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".
