How to: entity cache refresh/synchronization at runtime

[earlgrey]

Hi all,

the Jboss-API apparently does not provide a "cache refresh" at runtime.

1) How would I go on about synchronizing entity states in case of external data manipulation (low level db-access)? We are not happy with cache-commit-option C and D since our sync-problem only applies to one type of entity - whereas the cache options apply to the entire cache. Thus, we would suffer a loss of performance on many other entities.


2) Has anyone done their own entity-cache-implementation that would allow for a configuration at entity-type-level (cache-commit-option D would perfectly serve our needs if applicable to a specific type of entity)?


Thanks,

Lars

[vincent]

> Hi all,
>
> the Jboss-API apparently does not provide a "cache
> refresh" at runtime.
>
> 1) How would I go on about synchronizing entity
> states in case of external data manipulation (low
> level db-access)? We are not happy with
> cache-commit-option C and D since our sync-problem
> only applies to one type of entity - whereas the
> cache options apply to the entire cache. Thus, we
> would suffer a loss of performance on many other
> entities.

You can add your own config and use different ones for differet entities. Maybe I am missing a point...
>
>
> 2) Has anyone done their own
> entity-cache-implementation that would allow for a
> configuration at entity-type-level
> (cache-commit-option D would perfectly serve our
> needs if applicable to a specific type of entity)?

Non portable accross containers (!)

>
>
> Thanks,
>
> Lars
>

[earlgrey]

Vincent,

>
> You can add your own config and use different ones
> for differet entities. Maybe I am missing a
> point...

hmm, maybe I missed the point: do we have one configuration per container and one container per instance? or do you suggest to configure multiple instances of Jboss?

> Non portable accross containers (!)

jboss.xml is not portable either? naturally, this would be a jboss-specific cache-configuration.

Thanks,

Lars

[vincent]

I mean that if you need commit-option C for some entity beans and commit-option D for other and ...

You can create other configurations in standardjboss.xml:
Standard CMP Entity Bean C
Standard CMP Entity Bean A

And refer to them in the jboss.xml for your different entities

You are not force to use "Standard CMP Entity Bean" for ALL your cmp entity bean.

You can even imagine have ONE configuration per entity bean and define it in jboss.xml (standardjboss.xml is no more than default values for jboss.xml)

Are you with me ? or Am I with you ?

[earlgrey]

Thanks, Vincent!

I´m with you. This is what I was after.
I also just took a deep step into the new docu (SAMS book - very good reading, btw.) -
and here we go:


We have already seen nearly every element of the jboss.xml descriptor shown in Figure 9-1.
The exceptions are the top-level enforce-ejb-restricitions element and the configuration-name
element under each of the EJB element types...

The configuration-name element is a link to a container-configurations/container-configuration
element in Figure 9-2. It specifies which container configuration to use for the
referring EJB. The link is from a configuration-name element to a container-name element.
You are able to specify container configurations per class of EJB by including a container-configuration
element in the EJB definition. Typically one does not define completely new
container configurations, although this is supported. The typical usage of a jboss.xml level
container-configuration is to override one or more aspects of a container-configuration
coming from the standardjboss.xml descriptor. This is done by first specifying the name of
an existing standardjboss.xml container-configuration/container-name as the value for the
EJB configuration-name element. The desired standardjboss.xml descriptor container-configuration
elements are then overridden by including a jboss.xml container-configuration
that specifies the elements that are to be overridden.


I love spending $10 on docu...
(the clustering stuff is excellent as well),

Lars