-
1. Re: question about commit-option and
fox_hk Nov 11, 2002 10:15 PM (in response to fox_hk)l forgot to mention l use jboss 2.4.8 on win 2000
-
2. Re: question about commit-option and
vickyk Nov 11, 2002 11:24 PM (in response to fox_hk)Hi fox,
> 1) l have set the commit option to C. Hence,a CMP
> will be synchronzied with db as it is invoked. It
> seems that making the cache pool size bigger than 1
> become pointless. Am l correct ?
Why are setting the cache pool size,the commit option C just specifies the instance will remain in the ready State till the mapped data is available or timeout reaches or you call remove.I have never set the cache pool size but I do change the commit options.Any way there will be just a single instance for a particular CMP at any instance of time.
> 2) As l set the cache size to a very small value. l
> find that findbyPrimaryKey method will fail to
> retrieve the CMP as a large amount of CMP (~100) are
> retrieved in a for loop. But as l set it the cache
> size to a very big value. The "findbyPrimaryKey"
> method invoked within that for loop will function
> properly. WHY ???
Are you able to get the Collection of the Remote Reference,I mean does your findermethod fails while giving you the remote reference or when you manapulate a particular bean instance from the Collection returened from findermethod?
Regards
Vicky -
3. Re: question about commit-option and
fox_hk Nov 12, 2002 2:26 AM (in response to fox_hk)the snippet of code is as follows
for(..){
remoteref = homehandle.findbyPrimaryKey();
System.out.println(remoteref.getPrimarykey());
remoteref.setxxx(value obj);
}
The print statement can successfully print out the primary key. It fail when setter is called. But when l checked the error log, l find the persistence manager will issue a SQL select statement to load columns data from db. Primary key will be passed as parameter for that SQL statement. Amid for loop, when invocation of setter failed, l find a null parameter is passed to that SQL select statement. When l increase the cache size, the for loop can execute more times before it hit the same problem. Why ??? any idea ??? Is it a bug in jboss 2.4.8
many thanks
fox -
4. Re: question about commit-option and
vickyk Nov 14, 2002 4:58 AM (in response to fox_hk)Hi,
Can you try this with Jboss3.*?
Ideally it should not happen as per my undestanding.As you are setting the max pool size to 1 and as you keep on iterating the finder the instance move from the pooled state to readystate(cached state) where it should remain till the timeout called by container is called or forced by some restriction (here I mean the max limit specified)
Regards
Vicky -
5. Re: question about commit-option and
fox_hk Nov 14, 2002 11:05 PM (in response to fox_hk)Sorry, my system is using jboss 2.4.x to carry out development by far. we can't afford to upgrade to 3.x. It may involves so much changes. Yes, l set the cache size to 1 and pool size to a high value. But l also try out a medium cache size such as 10,20. But the problem exists too. But the exception just take place after for-loop run more times.
many thanks
fox -
6. Re: question about commit-option and
vickyk Nov 15, 2002 2:40 AM (in response to fox_hk)Hi,
What is making you to change the cache size? Is you application running short of the resource(memory)?
I will try the same with 3.0.2 and let you know but not now as I have some assignment lying to finish
Regards
Vicky -
7. Re: question about commit-option and
fox_hk Nov 17, 2002 10:24 PM (in response to fox_hk)Dear Vicky
thank for your kind attention to my question. Because my db is shared by other app, l change the commit-option to C. l think the "cache" can't do any good to the performance of entity bean. l tried out various cache size and monitor the server.log file. l found that cache size makes no difference in SQL statements issued by persistence manager, Is it a wiser choice to turn off the cache pool because l found that the abovementioned disappear if cache pool is off. Because is my configuration. Please comment on it.
<container-cache-conf>
<cache-policy>org.jboss.ejb.plugins.NoPassivationCachePolicy</cache-policy>
<!--
cache-policy-conf>
<min-capacity>10</min-capacity>
<max-capacity>60</max-capacity>
<overager-period>300</overager-period>
<max-bean-age>600</max-bean-age>
<resizer-period>400</resizer-period>
<max-cache-miss-period>60</max-cache-miss-period>
<min-cache-miss-period>1</min-cache-miss-period>
<cache-load-factor>0.75</cache-load-factor>
</cache-policy-conf>
-->
</container-cache-conf>
<container-pool-conf>
60
10
</container-pool-conf>
<commit-option>C</commit-option>