-
1. Re: commit-option "C" implies cache pool of CMP becomes of n
seven Nov 18, 2002 8:09 PM (in response to fox_hk)Yep. Take a look at the specs (EJB specs from java.sun.com). Commit option B makes the entity cahe unusable too. With those options, the container loads (via ejbLoad) the entity from the DB at the begining of a new transaction. The only commit option you can use in order to cache your entities betwen transactions is commit option A. But u can't use the last one if u share your DB with other apps.
-
2. Re: commit-option "C" implies cache pool of CMP becomes of n
fox_hk Nov 19, 2002 7:17 AM (in response to fox_hk)Hi all
l tried out comment out the tag <container-cache-conf> / <cache-policy-conf>, but jboss rejected it even the DTD of jboss.xml allow to do so (weird ??). What l am concerned is whether or not using the tag
"<cache-policy>org.jboss.ejb.plugins.NoPassivationCachePolicy</cache-policy>" is technically equivalent to switch off cache pool. Because the manual just say that this policy will make CMP not passivate. It doesn't explicitely say what happen when the max pool size is reached ....
Please advice
fox -
3. Re: commit-option "C" implies cache pool of CMP becomes of n
vickyk Nov 20, 2002 12:35 AM (in response to fox_hk)Hi
> Hi All
>
> Because my db is shared by other app, l set the
> commit-option to C. In this case, l think the "cache
> pool" for entity bean CANNOT do any good to the
> performance of entity bean. l tried out various cache
> pool size and monitored the server.log file. l found
> that cache size made no difference in SQL statements
> issued by persistence manager, Is it a wiser choice
> to turn off the cache pool ? Below is my
> configuration, it is thankful you can comment on it
> if it is no appropriate.
>
> <container-cache-conf>
> <cache-policy>org.jboss.ejb.plugins.NoPassivationCache
> olicy</cache-policy>
Let me share my opinion and my understanding,I dont have have the docs and I have learnt the Jboss management just by applying the basics and referring to the Quick ref pdf.
I do agree with you but considering that there being some sort of the blockage in the method call which can result in cpu sit idle.At the same moment take a scenario where all the bean-pooled instance are busy in calling mean while a fresh call has appeared then what happens?
Here I can visualize two possibility one at the appearance of call it find a bean calling the method having blockage,hence the bean is passivate at this momemt and serves the other call.So here there can be caching coming in the picture.
So if you make the changes in
<container-pool-conf>
60
10
</container-pool-conf>
I think you get some thing you expect I mean the caching.
Hope you share some more info .
Regards
Vicky -
4. Re: commit-option "C" implies cache pool of CMP becomes of n
vickyk Nov 20, 2002 12:49 AM (in response to fox_hk)Hi
> Hi All
>
> Because my db is shared by other app, l set the
> commit-option to C. In this case, l think the "cache
> pool" for entity bean CANNOT do any good to the
> performance of entity bean. l tried out various cache
> pool size and monitored the server.log file. l found
> that cache size made no difference in SQL statements
> issued by persistence manager, Is it a wiser choice
> to turn off the cache pool ? Below is my
> configuration, it is thankful you can comment on it
> if it is no appropriate.
>
> <container-cache-conf>
> <cache-policy>org.jboss.ejb.plugins.NoPassivationCache
> olicy</cache-policy>
Let me share my opinion and my understanding,I dont have have the docs and I have learnt the Jboss management just by applying the basics and referring to the Quick ref pdf.
I do agree with you but considering that there being some sort of the blockage in the method call which can result in cpu sit idle.At the same moment take a scenario where all the bean-pooled instance are busy in calling mean while a fresh call has appeared then what happens?
Here I can visualize two possibility one at the appearance of call it find a bean calling the method having blockage,hence the bean is passivate at this momemt and serves the other call.So here there can be caching coming in the picture.
So if you make the changes in
<container-pool-conf>
60
10
</container-pool-conf>
I think you get some thing you expect I mean the caching.
Hope you share some more info .
Regards
Vicky -
5. Re: commit-option "C" implies cache pool of CMP becomes of n
fox_hk Nov 21, 2002 11:35 PM (in response to fox_hk)Dear vicky
thanks you very much for your response. But l can't get your point. How can cache affect passivation in the case you quoted ??? It is highly appreciated if you can elaborate on it further
regards
fox -
6. Re: commit-option "C" implies cache pool of CMP becomes of n
vickyk Nov 22, 2002 1:06 AM (in response to fox_hk)Hi fox,
Considering there the limit of 10 beans in cache and if the load increases and there are not beans in the pooled state to serve the request.What will happen then?
Two Cases:
1)The request has to wait till the bean instance is returned to pooled instance,which will happen once the transaction ends up.(In case of the Commit Option B)
2)Pick up the bean from the cache which is waiting for some resource,if available(I mean if such entity exists).If this is found then till the time resource is made available to that you can make the same instance serve the addition request appeared.So there comes your passivation.The passivation is just the data instance state getting stored.
I am talking of the second case which can occur of the heavy load.
Hope now it is clearer ,I am extremely sorry for the last post not properly explained.
Regards
Vicky