Philippe Coq wrote:
> Eric Richardson wrote:
> >
> > Hi,
> > I have read most of EJB book from O'Reilly but not the spec. I was
> > wondering if the
> > load and store methods have to be called with every method invocation.
> >
> > Isn't there some way with Container Managed persistence to see if the
> > container managed
> > field have changed before these are called? I can see why with bean
> > managed they have to be called because the bean can delegate to another
> > object and a state change can't be known.
> >
> > I'm getting pretty gross performance when a retrieve more than a couple
> > of records. And once the
> > beans are loaded, it isn't substantially faster.
> >
> > Is this just the remote call latency? Can the server be optimized?
> >
> > Thanks,
> > Eric :-)
Phillipe,
Thanks for the reply-the isModified addition just about doubled read and write
performance for my test program. I know it's
not a fair comparison due to RPC and the services provided by EJB, but it's about 20
times slower than raw JDBC but I didn't
to write any JDBC, did I?
Eric :-)
>
>
> Hi Eric,
> If you have a look in the archive of jonas-users mailing list you can
> find
> that I have already answered to this question. Here is the answer I have
> made
> some time ago:
> in fact the data are nor loaded at instantiation time but at the call
> of the first business method inside a transaction.
> If you are in Container Managed Persistence the container read
> the managed field just before to call the Bean in ejbLoad.
> Synchronization objects are associated to the instances of the beans
> these objects are notified of the beginning of the commit process
> by the beforeCompletion() operation. this method call the bean in
> ejbStore and then update the state of the entity in the database.
> The problem is that if we do transaction with methods that doesn't
> change the state the bean the container will still perform database
> updates.
> If you are outside a transaction the container must write the contents
> of the bean after every invocation
> as the container has no way of knowing that the bean's contents haven't
> been modified by the invocation.
> In order to improve performance we have implemented in JOnAS (but it is
> not documented((I don't know why...)) the isModified extension of
> Weblogic.
> Before performing an update the container will call a method of the bean
> (whose name is indicated in the isModifiedMethodName of the
> EnvironmentProperties). this method is responsible to tell if the state
> of the bean has been changed.
> This mechanism is illustrated in attached files.
>
> Philippe
>
> Philippe Coq Groupe Bulll/BullSoft/OpenMaster Phone: (33) 04 76 29 78
> 49
> Bull S.A - 1 rue de Provence - 38432 Echirolles Cedex France
> [EMAIL PROTECTED] http://www-frec.bull.com
> Download our EJBServer at http://www.bullsoft.com/ejb
>
>
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
