Gaurav Sahni Messages: 19 Registered: September 2010
Junior Member
Hi jason
As you mentioned in another thread that how to set up the cache so i have used these following enteries for setting the cache
task.getAppContext().put("org.eclipse.birt.data.engine.dataset.cache.option ", "Yes");
task.getAppContext().put("org.eclipse.birt.data.cache.RowLimit ", new Integer(500));
task.getAppContext().put("org.eclipse.birt.data.cache.memory ", new Integer(500));
it also increased the performance little bit Please let me know is this the right way to use the caching in BIRT servlet
The first option you have has been deprecated and is not needed. The
second two options have to do with design time caching and really should
not be used in runtime. Try using:
"org.eclipse.birt.data.query.ResultBufferSize"
This setting determines how much of the data is cached in memory before
writing to disk. It defaults to 10mb. Set it to an integer.
Jason
On 9/27/2010 10:08 AM, Gaurav Sahni wrote:
> Hi jason
>
> As you mentioned in another thread that how to set up the cache so i
> have used these following enteries for setting the cache
> task.getAppContext().put("org.eclipse.birt.data.engine.dataset.cache.option
> ", "Yes");
> task.getAppContext().put("org.eclipse.birt.data.cache.RowLimit ", new
> Integer(500));
> task.getAppContext().put("org.eclipse.birt.data.cache.memory ", new
> Integer(500));
>
>
> it also increased the performance little bit Please let me know is this
> the right way to use the caching in BIRT servlet
>
Gaurav Sahni Messages: 19 Registered: September 2010
Junior Member
Hi jason
as you mention the following two options should not be used runtime what does it mean and also it runs reports faster if i set these two parameter
task.getAppContext().put("org.eclipse.birt.data.cache.RowLimit ", new Integer(500));
task.getAppContext().put("org.eclipse.birt.data.cache.memory ", new Integer(500));
and while setting "org.eclipse.birt.data.query.ResultBufferSize"
for 100 mb it does not show any performance improvements and aslo in log it say cache use 0 seconds something like that
andl also if we use the birt viewer instaed of writing own servlet then how to set this cache in Birt Viewer
On 9/28/2010 1:16 PM, Gaurav Sahni wrote:
> Hi jason
> as you mention the following two options should not be used runtime what
> does it mean and also it runs reports faster if i set these two parameter
>
> task.getAppContext().put("org.eclipse.birt.data.cache.RowLimit ", new
> Integer(500));
> task.getAppContext().put("org.eclipse.birt.data.cache.memory ", new
> Integer(500));
>
> and while setting "org.eclipse.birt.data.query.ResultBufferSize"
>
> for 100 mb it does not show any performance improvements and aslo in log
> it say cache use 0 seconds something like that
> andl also if we use the birt viewer instaed of writing own servlet then
> how to set this cache in Birt Viewer
>
> Thanks for all replies
>
>
>
sidharth mv Messages: 9 Registered: July 2012 Location: India
Junior Member
Hello Jason,
I am using BIRT runtime to view reports. So when I use complex queries with huge data, I need a caching mechanism for repeated access. Can you suggest how to achieve this. I have tried putting in URL the following parameter __overwrite. But I am passing parameters within report. Is it possible to define for each report to use a 30MB or 50MB memory to use as cache? So that repeated processing can avoid.
BIRT by default caches datasets already. If you mean by multiple
sessions your can always save the rptdocument and re-render it. Just
use &__document=docname.rptdesign in the URL of the viewer.
Jason
On 8/14/2012 3:44 AM, sidharth mv wrote:
> Hello Jason,
>
> I am using BIRT runtime to view reports. So when I use complex queries
> with huge data, I need a caching mechanism for repeated access. Can you
> suggest how to achieve this. I have tried putting in URL the following
> parameter __overwrite. But I am passing parameters within report. Is it
> possible to define for each report to use a 30MB or 50MB memory to use
> as cache? So that repeated processing can avoid.
>
> Thanks in advance,
> Sidharth