Though mixing BMP and CMP may not be a very good idea
when it comes to state management, I think it is a pretty
good idea on on of two cases.

1. When the bean needs to access some other table in the
   database other than the one it is mapped to. It could go
   to an external database. In this case, the state can be
   managed by CMP and the external database can be accessed
   using BMP. This way, portability too will not be a major
   issue.

2. When the bean needs to access a totally different type of
   data source. For instance, the bean may need to read some
   data from a legacy system apart from the CM database fields.

Any more ideas ?
RS

On Wed, 11 Aug 1999 15:46:57 GMT, Ed Roman <[EMAIL PROTECTED]> wrote:

>Comments below..
>
>From: Rickard �berg <[EMAIL PROTECTED]>
>>
>>I'm not saying we should mix BMP and CMP. The SQL calls I
>>referred to was not intended for state mgmt. For state mgmt you
>>should choose either or. I just meant that in bean methods you are
>>allowed to do whatever, including SQL-calls. Now, in the end I
>>think that databases are just another external resource, and
>>external resources will be available with the Connector API. Should
>>it be allowed to call legacy systems but not databases? Makes no
>>sense to me.
>>
>
>Agree here.  If an entity bean can access a connector, it should be able to
>access a database via SQL calls.
>
>>You meant per-variable level right? Having BMP/CMP decided on method
>>level does not make sense.
>
>True, but you also need to specify BMP/CMP on a per-finder method level
>because finder methods are not tied to variables.
>
>This raises some other hairy issues, like what if one of your variables is
>container-managed while another variable is bean-managed?  How do you do a
>find then?  Ugh.  Perhaps mixing BMP with CMP isn't such a hot idea.
>
>-Ed
>
>
>_______________________________________________________________
>Get Free Email and Do More On The Web. Visit http://www.msn.com
>
> ==========================================================================
>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".

Reply via email to