> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of John Harby
> Thanks for responding. On the second issue (the pre-caching),
> I was thinking it would be created on deployment and be some sort
> of configurable LRU managed by the DBMS.
The EJB's are typically deployed at startup-time, and I can anticipate the
following problems with your proposal:
- The start-up time of the server will be much longer (not necessarily a big
deal)
- The database might not contain all the data you need yet, or
- By the time you invoke your EJB, the data it will have pre-loaded will be
stale
The pro of your approach would be:
- Very fast first access to the bean
It seems to be a hefty price to pay for only a marginal gain...
> About the competing process consideration. Suppose I *knew* that no
> non-appserver process would modify my CMP table.
Okay, so you have two nodes in your cluster, in which all entity beans
compete for the same tables.
> Couldn't I have a
> low-maintenance bitmap replicated in the cluster. This bitmap
> would tell me the status of the CMP tables so that I could simply check
the
> bitmap (n x n binary matrix) before my load went to the db? I would try to
argue much on
> this because I know there are probably many proprietary optimizations in
> place that would nullify this benefit.
It seems to me that you are basically describing optimistic locking at the
container level, and yes, I agree, it is useful.
--
Cedric
===========================================================================
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".
