Re: embedded derby small foot print

2011-07-18 Thread Dag H. Wanvik
Paul French paul.fre...@kirona.com writes:

 We run derby 10.5.1 on J9 on WM6.1/6.5

 The derby web site claims a small foot print of 2.6MB ? How do I
 achieve this? What is the 2.6MB actually measuring, heap, non-heap,
 both ?

 Our application is hitting resource problems on WM, so we need to tune
 all parts of the app as much as possible. For derby the only setting
 we have played with is:

 Dderby.storage.pageCacheSize=50

 ...which helps, but derby still looks like it is using 7M. Any ideas?

The 2.6Mb is the size of the code bundle. How much memory you need at
run time depends on your application and settings, and your milage may
vary. Make sure explicitly close resources as you go.

You could try to limit the heap with -XmxXM and see how far doown
you can squeeze it. The minimum value for derby.storage.pageCacheSize is
40.

Also, you could try to disable the prepared statement cache trading
speed for space: Setting derby.language.statementCacheSize to 0 disables
it (default is 100). 

Dag


Re: How to unlock a table in derby

2011-07-18 Thread Lahiru Gunathilake
I will try it, thank you Byan !

Lahiru

On Fri, Jul 15, 2011 at 8:47 PM, Bryan Pendleton bpendleton.de...@gmail.com
 wrote:

  I execute query lock table table name
 in share mode but I cannot see any documentation on how to unlock a derby
 table.


 Commit.

 thanks,

 bryan




Re: How to unlock a table in derby

2011-07-18 Thread Peter Ondruška
Rollback might work as well :)
Dne 18.7.2011 15:57 Lahiru Gunathilake glah...@gmail.com napsal(a):
 I will try it, thank you Byan !

 Lahiru

 On Fri, Jul 15, 2011 at 8:47 PM, Bryan Pendleton 
bpendleton.de...@gmail.com
 wrote:

 I execute query lock table table name
 in share mode but I cannot see any documentation on how to unlock a
derby
 table.


 Commit.

 thanks,

 bryan




Re: embedded derby small foot print

2011-07-18 Thread Paul French

Thanks Dag for the info.


On 18/07/2011 14:50, Dag H. Wanvik wrote:

Paul Frenchpaul.fre...@kirona.com  writes:


We run derby 10.5.1 on J9 on WM6.1/6.5

The derby web site claims a small foot print of 2.6MB ? How do I
achieve this? What is the 2.6MB actually measuring, heap, non-heap,
both ?

Our application is hitting resource problems on WM, so we need to tune
all parts of the app as much as possible. For derby the only setting
we have played with is:

Dderby.storage.pageCacheSize=50

...which helps, but derby still looks like it is using 7M. Any ideas?

The 2.6Mb is the size of the code bundle. How much memory you need at
run time depends on your application and settings, and your milage may
vary. Make sure explicitly close resources as you go.

You could try to limit the heap with -XmxXM and see how far doown
you can squeeze it. The minimum value for derby.storage.pageCacheSize is
40.

Also, you could try to disable the prepared statement cache trading
speed for space: Setting derby.language.statementCacheSize to 0 disables
it (default is 100).

Dag


Re: How to unlock a table in derby

2011-07-18 Thread Lahiru Gunathilake
Hi Byan,

I am creating the connection with autoCommit=true parameter, does this work
with derby or should I explicitly commit the transaction?


Lahiru

On Mon, Jul 18, 2011 at 9:58 AM, Peter Ondruška 
peter.ondruska+de...@kaibo.eu wrote:

 Rollback might work as well :)
 Dne 18.7.2011 15:57 Lahiru Gunathilake glah...@gmail.com napsal(a):

  I will try it, thank you Byan !
 
  Lahiru
 
  On Fri, Jul 15, 2011 at 8:47 PM, Bryan Pendleton 
 bpendleton.de...@gmail.com
  wrote:
 
  I execute query lock table table name
  in share mode but I cannot see any documentation on how to unlock a
 derby
  table.
 
 
  Commit.
 
  thanks,
 
  bryan
 
 



Re: How to unlock a table in derby

2011-07-18 Thread Bryan Pendleton

On 07/18/2011 07:16 AM, Lahiru Gunathilake wrote:

Hi Byan,

I am creating the connection with autoCommit=true parameter, does this work 
with derby or should I explicitly commit the
transaction?


Lahiru


I believe if you do this, the system will automatically insert a 'commit'
immediately after your 'lock table' statement, thus releasing the lock
immediately and making the lock not very useful.

When I use 'lock table', I always do it with autocommit=false.

thanks,

bryan