« Return to Thread: Derby Error Starting Glassfish

Re: Derby Error Starting Glassfish

by OpenXGroup Inc. :: Rate this Message:

Reply to Author | View in Thread

Hello,

Activate derby-lock-print 

Using this to settings: 
derby.locks.deadlockTrace=true 
derby.locks.monitor=true 

According to table/row lock: 

Changing the lock granularity for the table 
The LOCKSIZE clause allows you to override row-level locking for the specific table, 
if your system uses the default setting of row-level locking. (If your system is set for 
table-level locking, you cannot change the locking granularity to row-level locking, 
although Derby allows you to use the LOCKSIZE clause in such a situation without 
throwing an exception.) To override row-level locking for the specific table, set locking 
for the table to TABLE. If you created the table with table-level locking granularity, you 
can change locking back to ROW with the LOCKSIZE clause in the ALTER TABLE 
STATEMENT. For information about why this is sometimes useful, see Tuning Java DB. 

Links: 
 * http://db.apache.org/derby/docs/dev/devguide/cdevconcepts15366.html  
 * http://db.apache.org/derby/docs/dev/devguide/cdevconcepts23810.html  

Derby: 

By default, Derby is configured for row-level locking. Row-level locking uses more memory but allows greater concurrency, which works better in multi-user systems. Table-level locking works best with single-user applications or read-only applications. 


On Fri, May 1, 2009 at 10:59 AM, jsexton0 <jsexton0@...> wrote:

Hello -

This is interesting...
This error is happening on the Derby database, very early in Glassfish's
startup.  I am not (directly) using the Derby database in any of my code.
Are you suggesting a change to Glassfish's default setup for its Derby pool?
I can certainly try that...

Thanks


OpenXGroup Inc. wrote:
>
> Take a look at wrong XA state as well...
>
> Can you change javax.sql.ConnectionPoolDataSource to javax.sql.DataSource?
> Or use XA datasource altogether?
> I increased the "Initial and Minimum Pool Size" from 32 (default) to 64.
> The
> error vanished, but I don't know if it just depends on how many times per
> timer event a connection is requested. May be the error will occure again
> with more connection requests. Do you now what the maximal possible value
> is
> for the Initial and Minimum Pool Size? The value of 128 seemed not to be
> accepted.
>
> I was able to resolve my problem by changing the resource type to
> java.sql.ConnectionPoolDataSource.
>
> Do you need transactional capability. If not, you can set your pool to
> return non-transactional-connections.
>
> Set non-transactional-connections="true" in your <jdbc-connection-pool>
> configuration.
>
> There are two type of transactions we can talk about in general
> (pertaining
> to this thread).
>
> 1) There is the transaction that you can write using SQL which you (the
> programmer) write yourself.
> 2) There is the transaction that java handles at a system level which can
> apply to any operation or series of operations you require to be performed
> from beginning to end without error (including database operations).
>
> By setting non-transactional-connections to true you will not get the
> protection from system failure as described in number 2.
>
>
>

--
View this message in context: http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23334482.html
Sent from the NetBeans - EntPack mailing list archive at Nabble.com.


 « Return to Thread: Derby Error Starting Glassfish