Evan Ireland wrote:
> Among our customers, I see two distinct requirements for CMP.
>
> (1) CMP where the customer wants persistent objects, and couldn't care at all
> where or how their data is stored. (The spec allows Java Serialization to
> be used in this case).
>
> (2) CMP where the bean's persistence must map to database schemas that already
> exist or are created by the customer (in the RDBMS case, they may sometimes
> want to be able to use SQL to access their data).
>
> Where the customer wants the latter, I believe that tools that generate BMP
> code are an essential part of the equation, since no matter how 'clever' a CMP
> code generator is, it might not be adequate to meet the customer's requirements,
> so generating BMP code that the user can then modify is very useful.
>
> The back-end data sources that are accessible through CMP (or BMP) are so many
> and varied that I am not clear on what "Standard CMP" would look like. Once you
> have declared which fields in your bean are your "persistent state", anything
> else (apart from caching-type optimizations like being able to specify in the
> deployment descriptor that a method is read-only) is specific to the data
> store being used.
Agree completely. CMP through BMP is easily the most
powerful/flexible/portable method as it is not reliant on EJB-vendor.
> I would propose to the spec writers that the notion of 'read-only' method be
> specifiable in the deployment descriptors.
Pardon my ignorance: what happens if RO-methods are declared to be
TX_NOT_SUPPORTED? How do vendors handle this case? Are beans
synchronized with the DB before and after each call, or only when
activated/passivated, or after a timout?
One other technique to solve this seems to be implementing a clever
storing that checks if fields have been changed or not. If not fields
have been changed then no DB call is made. There is a thread somewhere
in the EJB-INTEREST archives along these lines.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
