Re: Performance?

[Rickard Öberg <rickard at telkel.com>]

Hi!

Marcel Ruff wrote:
> > Riddle me this:
> > On a particularly sunny and inspiring day you write not one but two
> > letters of poetry to your lady friend. You put them both in the mailbox,
> > and by noon the postman empties the box. The following day another
> > postman in another town carry the two to your girlies house, so that she
> > may read your fine words.
> >
> > The trick I use is described above.
> I believe you talk about a 'burst mode', collect and send in one flush.
> 
> We have this mode when publishing already.

You need it for both incoming and outgoing. If someone publishes a
message wait some time (a couple of seconds for example) and see if more
messages are published on that machine before sending it to the server.
To compare with the postman scenario, the more messages he empties from
the mailbox at once, the better. 

> > > The 62 requests per seconds of JBoss is strange, my EJbean looks like:
> > >
> > >   getXy() {
> > >         return xy;
> > >   }
> > >
> > > JBoss does allways call ejbStore() which is a Oracle UPDATE call,
> > > i believe this consumes a lot of performance.
> > > But why does JBOSS call ejbStore() on a simple get method?
> > > (it is a bean managed entity bean)
> >
> > ejbStore() is called at the end of a transaction. This is the EJB spec
> > rule. There are two ways to avoid it:
> > * In your BMP EntityBean you could have a flag "dirty" which you set to
> > true when state changes. In ejbStore you should check this flag and only
> > store if necessary.
> > * Convert your bean to a CMP one and use tuned updates. This will do the
> > above automatically.
> > * Convert your bean to a CMP one and keep a dirty flag and implement a
> > method "public boolean isModified()". jBoss will call it before it calls
> > "ejbStore" to test whether the state has changed or not.
> Thanks for these hints.
> I didn't read the spec now, but calling ejbStore() on a get() method
> seems strange to me (Suns reference implementation does not do it).

Actually, we had this optimization before (i.e. "get*" methods was not
considered to change state) but removed it since it was counter-spec. If
the J2EE RI does this by default it is also counter-spec, and a bug IMO.
We might add this back as a non-default option, but for now you can use
tuned updates which will check before and after state to see if
something has changed.

regards,
  Rickard

-- 
Rickard Öberg

Email: rickard at telkel.com
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com