Ward,
Thanks for the information.
I have been reading about about Cocobase in the mailing-list and I'm
curious.
I'll probably check out your product sometime next week.
I'm assuming you have a free evaluation download.
Thanks,
Murali Krishna Devarakonda
Senior Technical Consultant
IXL Inc., 1010 Battery Street
San Francisco, CA 94111
w: 415-217-8632
e: [EMAIL PROTECTED]
----- Original Message -----
From: Ward Mullins <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 26, 1999 1:11 PM
Subject: Re: Container managed persistence aspects
Hi Murali, in light of your posting, I thought you might find this
interesting...
<vendor>
We're readying release CMP compatible installer that will work with any
EJB server that fully implements EntityBeans. It also provides much
more sophisticate O/R than EJB servers do, and provides dynamic mapping
O/R so you can change map definitions without recompile or redeployment,
provides tunability for the resulting CMP code (including the ability to
actually modify the resulting code associated with the CMP if desired),
and it handles the smart updates automatically (although once again it's
tunable by you). It's also the only solution that's by default fully
table spanning and that fully decouples the Object model from the
relational model.
Ask your EJB vendor if they can make your entity bean span multiple
database tables, virtually none can - a VERY serious limititation in
default container implementations. Typically they either generate
separate beans for each table when they 'say' they support it, which
is a VERY resource, memory and cpu intensive design, and isn't really
table spanning support. So if you don't want to be bound to the
relational model as your object model, but you want the convenience
and 'portability' of CMP, check out our CocoBase Enterprise Relational
O/R product. We'll be releasing the CMP installer in a few days in beta :)
With CocoBase you not only have database independence, but you now have
EJB server independence without sacrificing your Object model in the
process...
</vendor>
THOUGHT Support
On Thu, 12 Aug 1999 13:02:16 -0700, Murali Krishna Devarakonda
<[EMAIL PROTECTED]> wrote:
>----- Original Message -----
>From: Aminadab Pereira Nunes <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Saturday, January 03, 1970 3:56 PM
>Subject: Container managed persistence aspects
>
>
>Hi there,
>
>I've got a question about entity beans with container-managed
>perisistence. In tests I notice that when you invoke an entity bean's
>access method (I mean a method that doesn't change the bean's
>attributes) within a transaction the container updates the bean's state
>at the database. In other words, if you access an entity bean, even
>without changing it, within a transaction, the rows that map this bean
>on the database are updated.
>
>Is it really supposed to be like that or is there somehow to specify
>that the bean's state hasn't been changed, and therefore doesn't need to
>be updated on the database ?
>
><MKD>
>It's currently vendor-specific. WebLogic has a simple isModified method
that
>let's the container know if an update has occured.
>
>Regards,
>Murali Krishna Devarakonda
></MKD>
>
> ==========================================================================
>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".
