Derby Error Starting Glassfish

[OpenXGroup Inc.]

The EJB Container timer service potentially can get corrupted if the Derby database files that store timer data get out of sync. To avoid this problem, use MySQL to store the timer data.  So you may need to move the ejb__timer__tbl from embedded db to an external db

Perhaps delete and re-create JDBC data source.....

When you restart GlassFIsh what is your ulimit set at?

restart GlassFish, type:

ulimit -n 32768

bin/asadmin start-domain domain1

http://thedata.org/guides/installers/maintenance/glassfish/utilities

On Fri, May 1, 2009 at 12:20 PM, jsexton0 <jsexton0@...> wrote:

Hello -

I unloaded some SAs, shutdown everything on my computer, restarted Glassfish
(it looked OK), and then reloaded the SAs one at a time and everything came
up and runs normally.

So it doesn't appear to be corrupted at least, it's just a problem with the
general start up process, when everything is loaded.

Thanks

Manfred Riem wrote:
>
> The only other thing I could recommend is to connect
> to the EJB timer database yourself and see if the
> database itself is not corrupted in anyway.
>
> Manfred
>
>> -------- Original Message --------
>> Subject: Re: [entpack] Derby Error Starting Glassfish
>> From: jsexton0 <jsexton0@...>
>> Date: Fri, May 01, 2009 9:49 am
>> To: nbentpack@...
>>
>>
>> Hello -
>>
>> I tried changing the max connections to 64, and the timeout to 90000 on
>> each
>> pool..
>>
>> __TimerPool
>> DerbyPool
>> iepseDerbyPoolNonXA
>> iepseDerbyPoolXA
>>
>> Still unable to startup Glassfish correctly, no change.  I do not know
>> were/how to set other Derby properties.  My server is
>> as-originally-installed with respect to the __TimerPool settings.
>>
>> I guess I'll have to try pointing it at a different database server
>> altogether.  I'd like to understand why this started happening however,
>> and
>> I hate having to make such a drastic change to the way Glassfish comes
>> "out
>> of the box".
>>
>> I do have one timer bean in my application, but it's been working fine
>> for
>> months as other development has progressed.  Nothing in particular seems
>> to
>> have caused this error to begin happening, except the application has
>> grown.
>>
>> Thanks
>>
>>
>> OpenXGroup Inc. wrote:
>> >
>> > Another thing to try- change connection-validation-method="auto-commit"
>> to
>> > be "table"?
>> > Can you change javax.sql.ConnectionPoolDataSource to
>> javax.sql.DataSource?
>> > Or use XA datasource altogether?
>> >
>> > When you use a timer, it comes with the XA datasource access because
>> the
>> > timer instances are stored in the database. When you call your method
>> > directly, it uses a single (non-XA) connection. And that is a big
>> > difference.
>> >
>> > More information about *how to diagnose a deadlock situation in Derby /
>> > Java
>> > DB*.
>> > http://wiki.apache.org/db-derby/LockDebugging
>> > http://db.apache.org/derby/docs/dev/devguide/cdevconcepts50894.html
>> >
>> > Note that lock ordering as part of the application is important (e.g.
>> > locking in same order) and that a table being accessed without an index
>> > could lead to a Table-level lock, affecting the lock granularity quite
>> > significantly and the risk of deadlocks as part of the applications. It
>> > seemed like some index might have been missing for some of the columns
>> > being
>> > searched as part of some queries.
>> >
>> >
>> > 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.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335261.html
>> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>
>
>

--
View this message in context: http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335749.html

Sent from the NetBeans - EntPack mailing list archive at Nabble.com.

[OpenXGroup Inc.]

Please examine the SQLException for more information.
NestedException: java.sql.SQLTransactionRollbackException: A lock could not
be obtained within the time requested

access - database corrupt

access - table issue (timer database table) - Indexing issue?

access - security issue

access - resource contention/management optimization issue (app has grown)
access - data source must be configured with an XA JDBC driver

EJB Timer Service settings

Timer DataSource - Specifies the database used by the EJB Timer Service. The default isjdbc/__TimerPool

Derby Bug?  I am very interested if this indeed is a Derby bug.

On Fri, May 1, 2009 at 2:30 PM, jsexton0 <jsexton0@...> wrote:

The cause of the timer service's failure to start, is the earlier SQL failure
to accessing the timer table in the Derby database.

OpenXGroup Inc. wrote:
>
> Down in the stack trace is EJB5108:Unable to initialize EJB Timer Service.
> The likely cause is the
> database has not been started or the timer database table has not been
> created.
>
> http://wiki.glassfish.java.net/Wiki.jsp?page=Ejb
>
> *How do you verify the EJB Timer Service is enabled?  Does this work: You
> can verify that it was deployed successfully by accessing the following
> URL:

> **http://localhost:8080/ejb-timer-service-app/timer*<http://localhost:8080/ejb-timer-service-app/timer>

> * *
>
> EJB5108 Unable to initialize EJB Timer Service. The likely cause is the
> database has not been started or the timer database table has not been
> created.Cause:The EJB Timer Service could not be initialized because a
> problem occurred while attempting to restore previously registered timers
> from the associated data source.Solution:*Double-check the JDBC data
> source
> (and its associated connection pool) assigned **to** the **EJB** **Timer**
> *
> *Service.* Common causes are that the database is not running, the timer
> table
> has not been created within that database, or that the connection pool's
> JDBC driver URL information is incorrect.
>
> This is how an older version of WAS did it with Cloudscape/Derby....
>
> What's probably happening is: something is preventing the
> timer/scheduler service from starting, back at the time this module (or
> some other module that also contains TimedObjects) is started. At the
> time an EJB module is started, the WAS EJB container looks to see if any
> beans within that module implement TimedObject. If any do, we attempt
> to start the scheduler service if it is not already running.
>
> When you see the message, it means that the EJB container is attempting
> to call the scheduler service, but the service is not started.* Some
> possible causes for the service being unable to start are:
>
> - Scheduler database not present
> - Database is present but scheduler tables are not present or are not
> defined correctly
> - Server does not have access authority to the scheduler database*
>
> *When you install WAS, it comes pre-configured out of the box to use an
> internal instance of a Cloudscape/Derby database for its scheduler data. *
> However, it is possible to configure the EJB Timer service (which in
> turn uses the scheduler service) to use an alternate database or
> scheduler instance. It's possible, if the scheduler/timer service
> config has been modified, that there could be a config problem that
> would prevent the scheduler from starting.
>
> In any case, there should be some messages further up in your system out
> log indicating that the scheduler had trouble starting, which should
> shed some light as to the cause.
>
> On Fri, May 1, 2009 at 12:20 PM, jsexton0 <jsexton0@...> wrote:
>
>>
>> Hello -
>>
>> I unloaded some SAs, shutdown everything on my computer, restarted
>> Glassfish
>> (it looked OK), and then reloaded the SAs one at a time and everything
>> came
>> up and runs normally.
>>
>> So it doesn't appear to be corrupted at least, it's just a problem with
>> the
>> general start up process, when everything is loaded.
>>
>> Thanks
>>
>>
>> Manfred Riem wrote:
>> >
>> > The only other thing I could recommend is to connect
>> > to the EJB timer database yourself and see if the
>> > database itself is not corrupted in anyway.
>> >
>> > Manfred
>> >
>> >> -------- Original Message --------
>> >> Subject: Re: [entpack] Derby Error Starting Glassfish
>> >> From: jsexton0 <jsexton0@...>
>> >> Date: Fri, May 01, 2009 9:49 am
>> >> To: nbentpack@...
>> >>
>> >>
>> >> Hello -
>> >>
>> >> I tried changing the max connections to 64, and the timeout to 90000
>> on
>> >> each
>> >> pool..
>> >>
>> >> __TimerPool
>> >> DerbyPool
>> >> iepseDerbyPoolNonXA
>> >> iepseDerbyPoolXA
>> >>
>> >> Still unable to startup Glassfish correctly, no change.  I do not know
>> >> were/how to set other Derby properties.  My server is
>> >> as-originally-installed with respect to the __TimerPool settings.
>> >>
>> >> I guess I'll have to try pointing it at a different database server
>> >> altogether.  I'd like to understand why this started happening
>> however,
>> >> and
>> >> I hate having to make such a drastic change to the way Glassfish comes
>> >> "out
>> >> of the box".
>> >>
>> >> I do have one timer bean in my application, but it's been working fine
>> >> for
>> >> months as other development has progressed.  Nothing in particular
>> seems
>> >> to
>> >> have caused this error to begin happening, except the application has
>> >> grown.
>> >>
>> >> Thanks
>> >>
>> >>
>> >> OpenXGroup Inc. wrote:
>> >> >
>> >> > Another thing to try- change
>> connection-validation-method="auto-commit"
>> >> to
>> >> > be "table"?
>> >> > Can you change javax.sql.ConnectionPoolDataSource to
>> >> javax.sql.DataSource?
>> >> > Or use XA datasource altogether?
>> >> >
>> >> > When you use a timer, it comes with the XA datasource access because
>> >> the
>> >> > timer instances are stored in the database. When you call your
>> method
>> >> > directly, it uses a single (non-XA) connection. And that is a big
>> >> > difference.
>> >> >
>> >> > More information about *how to diagnose a deadlock situation in
>> Derby
>> /
>> >> > Java
>> >> > DB*.
>> >> > http://wiki.apache.org/db-derby/LockDebugging
>> >> > http://db.apache.org/derby/docs/dev/devguide/cdevconcepts50894.html
>> >> >
>> >> > Note that lock ordering as part of the application is important
>> (e.g.
>> >> > locking in same order) and that a table being accessed without an
>> index
>> >> > could lead to a Table-level lock, affecting the lock granularity
>> quite
>> >> > significantly and the risk of deadlocks as part of the applications.
>> It
>> >> > seemed like some index might have been missing for some of the
>> columns
>> >> > being
>> >> > searched as part of some queries.
>> >> >
>> >> >
>> >> > 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.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335261.html
>> >> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335749.html
>> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23337729.html

Sent from the NetBeans - EntPack mailing list archive at Nabble.com.

[jsexton0]

I did not set any of this up, the DB and pool are as originally installed with Netbeans/Glassfish for its EJB timer support.  And it can sometimes work, so a security issue, a corruption issue, and a table/schema issue can be ruled out.

It could very well be related to resource contention, but I don't know how I can control this.
The JDBC driver for Derby is whatever Glassfish comes with.

I'm not sure what EJB Timer Service settings are available in the server, but I have not changed anything.  I have not specificly looked for a timer section in the Glassfish console.  I'll do that.  I did try increasing the time out and the max connections on __TimerPool, but it did not change the problem.

It would be really nice if we did not has to change out the database provided.  That would greatly complicate the install process...

Thanks

OpenXGroup Inc. wrote:

Please examine the SQLException for more information.
NestedException: java.sql.SQLTransactionRollbackException: A lock could not
be obtained within the time requested
access - database corrupt
access - table issue (timer database table) - Indexing issue?
access - security issue
access - resource contention/management optimization issue (app has grown)
access - data source must be configured with an XA JDBC driver

EJB Timer Service settings

Timer DataSource - Specifies the database used by the EJB Timer Service. The
default isjdbc/__TimerPool

Derby Bug?  I am very interested if this indeed is a Derby bug.

On Fri, May 1, 2009 at 2:30 PM, jsexton0 <[e-mail]> wrote:
> The cause of the timer service's failure to start, is the earlier SQL
> failure
> to accessing the timer table in the Derby database.
>
>
> OpenXGroup Inc. wrote:
> >
> > Down in the stack trace is EJB5108:Unable to initialize EJB Timer
> Service.
> > The likely cause is the
> > database has not been started or the timer database table has not been
> > created.
> >
> > http://wiki.glassfish.java.net/Wiki.jsp?page=Ejb
> >
> > *How do you verify the EJB Timer Service is enabled?  Does this work: You
> > can verify that it was deployed successfully by accessing the following
> > URL:
> > **http://localhost:8080/ejb-timer-service-app/timer*<
> http://localhost:8080/ejb-timer-service-app/timer>
> > * *
> >
> > EJB5108 Unable to initialize EJB Timer Service. The likely cause is the
> > database has not been started or the timer database table has not been
> > created.Cause:The EJB Timer Service could not be initialized because a
> > problem occurred while attempting to restore previously registered timers
> > from the associated data source.Solution:*Double-check the JDBC data
> > source
> > (and its associated connection pool) assigned **to** the **EJB**
> **Timer**
> > *
> > *Service.* Common causes are that the database is not running, the timer
> > table
> > has not been created within that database, or that the connection pool's
> > JDBC driver URL information is incorrect.
> >
> > This is how an older version of WAS did it with Cloudscape/Derby....
> >
> > What's probably happening is: something is preventing the
> > timer/scheduler service from starting, back at the time this module (or
> > some other module that also contains TimedObjects) is started. At the
> > time an EJB module is started, the WAS EJB container looks to see if any
> > beans within that module implement TimedObject. If any do, we attempt
> > to start the scheduler service if it is not already running.
> >
> > When you see the message, it means that the EJB container is attempting
> > to call the scheduler service, but the service is not started.* Some
> > possible causes for the service being unable to start are:
> >
> > - Scheduler database not present
> > - Database is present but scheduler tables are not present or are not
> > defined correctly
> > - Server does not have access authority to the scheduler database*
> >
> > *When you install WAS, it comes pre-configured out of the box to use an
> > internal instance of a Cloudscape/Derby database for its scheduler data.
> *
> > However, it is possible to configure the EJB Timer service (which in
> > turn uses the scheduler service) to use an alternate database or
> > scheduler instance. It's possible, if the scheduler/timer service
> > config has been modified, that there could be a config problem that
> > would prevent the scheduler from starting.
> >
> > In any case, there should be some messages further up in your system out
> > log indicating that the scheduler had trouble starting, which should
> > shed some light as to the cause.
> >
> > On Fri, May 1, 2009 at 12:20 PM, jsexton0 <[e-mail]> wrote:
> >
> >>
> >> Hello -
> >>
> >> I unloaded some SAs, shutdown everything on my computer, restarted
> >> Glassfish
> >> (it looked OK), and then reloaded the SAs one at a time and everything
> >> came
> >> up and runs normally.
> >>
> >> So it doesn't appear to be corrupted at least, it's just a problem with
> >> the
> >> general start up process, when everything is loaded.
> >>
> >> Thanks
> >>
> >>
> >> Manfred Riem wrote:
> >> >
> >> > The only other thing I could recommend is to connect
> >> > to the EJB timer database yourself and see if the
> >> > database itself is not corrupted in anyway.
> >> >
> >> > Manfred
> >> >
> >> >> -------- Original Message --------
> >> >> Subject: Re: [entpack] Derby Error Starting Glassfish
> >> >> From: jsexton0 <[e-mail]>
> >> >> Date: Fri, May 01, 2009 9:49 am
> >> >> To: [e-mail]
> >> >>
> >> >>
> >> >> Hello -
> >> >>
> >> >> I tried changing the max connections to 64, and the timeout to 90000
> >> on
> >> >> each
> >> >> pool..
> >> >>
> >> >> __TimerPool
> >> >> DerbyPool
> >> >> iepseDerbyPoolNonXA
> >> >> iepseDerbyPoolXA
> >> >>
> >> >> Still unable to startup Glassfish correctly, no change.  I do not
> know
> >> >> were/how to set other Derby properties.  My server is
> >> >> as-originally-installed with respect to the __TimerPool settings.
> >> >>
> >> >> I guess I'll have to try pointing it at a different database server
> >> >> altogether.  I'd like to understand why this started happening
> >> however,
> >> >> and
> >> >> I hate having to make such a drastic change to the way Glassfish
> comes
> >> >> "out
> >> >> of the box".
> >> >>
> >> >> I do have one timer bean in my application, but it's been working
> fine
> >> >> for
> >> >> months as other development has progressed.  Nothing in particular
> >> seems
> >> >> to
> >> >> have caused this error to begin happening, except the application has
> >> >> grown.
> >> >>
> >> >> Thanks
> >> >>
> >> >>
> >> >> OpenXGroup Inc. wrote:
> >> >> >
> >> >> > Another thing to try- change
> >> connection-validation-method="auto-commit"
> >> >> to
> >> >> > be "table"?
> >> >> > Can you change javax.sql.ConnectionPoolDataSource to
> >> >> javax.sql.DataSource?
> >> >> > Or use XA datasource altogether?
> >> >> >
> >> >> > When you use a timer, it comes with the XA datasource access
> because
> >> >> the
> >> >> > timer instances are stored in the database. When you call your
> >> method
> >> >> > directly, it uses a single (non-XA) connection. And that is a big
> >> >> > difference.
> >> >> >
> >> >> > More information about *how to diagnose a deadlock situation in
> >> Derby
> >> /
> >> >> > Java
> >> >> > DB*.
> >> >> > http://wiki.apache.org/db-derby/LockDebugging
> >> >> >
> http://db.apache.org/derby/docs/dev/devguide/cdevconcepts50894.html
> >> >> >
> >> >> > Note that lock ordering as part of the application is important
> >> (e.g.
> >> >> > locking in same order) and that a table being accessed without an
> >> index
> >> >> > could lead to a Table-level lock, affecting the lock granularity
> >> quite
> >> >> > significantly and the risk of deadlocks as part of the
> applications.
> >> It
> >> >> > seemed like some index might have been missing for some of the
> >> columns
> >> >> > being
> >> >> > searched as part of some queries.
> >> >> >
> >> >> >
> >> >> > On Fri, May 1, 2009 at 10:59 AM, jsexton0 <[e-mail]>
> >> 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.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335261.html
> >> >> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335749.html
> >> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23337729.html
> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>
>

[jsexton0]

Hello -

Today, I'm working on a Windows machine so no ulimit utility.
I have the same app on a linux though, and have seen the error there too.  It behaves very much the same way.

Where is the derby database file?

Thanks

OpenXGroup Inc. wrote:

The EJB Container timer service potentially can get corrupted if the Derby
database files that store timer data get out of sync. To avoid this problem,
use MySQL to store the timer data.  So you may need to move the
ejb__timer__tbl from embedded db to an external db


Perhaps delete and re-create JDBC data source.....

When you restart GlassFIsh what is your ulimit set at?

restart GlassFish, type:

*ulimit -n 32768

bin/asadmin start-domain domain1 *

http://thedata.org/guides/installers/maintenance/glassfish/utilities


On Fri, May 1, 2009 at 12:20 PM, jsexton0 <[e-mail]> wrote:

>
> Hello -
>
> I unloaded some SAs, shutdown everything on my computer, restarted
> Glassfish
> (it looked OK), and then reloaded the SAs one at a time and everything came
> up and runs normally.
>
> So it doesn't appear to be corrupted at least, it's just a problem with the
> general start up process, when everything is loaded.
>
> Thanks
>
>
> Manfred Riem wrote:
> >
> > The only other thing I could recommend is to connect
> > to the EJB timer database yourself and see if the
> > database itself is not corrupted in anyway.
> >
> > Manfred
> >
> >> -------- Original Message --------
> >> Subject: Re: [entpack] Derby Error Starting Glassfish
> >> From: jsexton0 <[e-mail]>
> >> Date: Fri, May 01, 2009 9:49 am
> >> To: [e-mail]
> >>
> >>
> >> Hello -
> >>
> >> I tried changing the max connections to 64, and the timeout to 90000 on
> >> each
> >> pool..
> >>
> >> __TimerPool
> >> DerbyPool
> >> iepseDerbyPoolNonXA
> >> iepseDerbyPoolXA
> >>
> >> Still unable to startup Glassfish correctly, no change.  I do not know
> >> were/how to set other Derby properties.  My server is
> >> as-originally-installed with respect to the __TimerPool settings.
> >>
> >> I guess I'll have to try pointing it at a different database server
> >> altogether.  I'd like to understand why this started happening however,
> >> and
> >> I hate having to make such a drastic change to the way Glassfish comes
> >> "out
> >> of the box".
> >>
> >> I do have one timer bean in my application, but it's been working fine
> >> for
> >> months as other development has progressed.  Nothing in particular seems
> >> to
> >> have caused this error to begin happening, except the application has
> >> grown.
> >>
> >> Thanks
> >>
> >>
> >> OpenXGroup Inc. wrote:
> >> >
> >> > Another thing to try- change
> connection-validation-method="auto-commit"
> >> to
> >> > be "table"?
> >> > Can you change javax.sql.ConnectionPoolDataSource to
> >> javax.sql.DataSource?
> >> > Or use XA datasource altogether?
> >> >
> >> > When you use a timer, it comes with the XA datasource access because
> >> the
> >> > timer instances are stored in the database. When you call your method
> >> > directly, it uses a single (non-XA) connection. And that is a big
> >> > difference.
> >> >
> >> > More information about *how to diagnose a deadlock situation in Derby
> /
> >> > Java
> >> > DB*.
> >> > http://wiki.apache.org/db-derby/LockDebugging
> >> > http://db.apache.org/derby/docs/dev/devguide/cdevconcepts50894.html
> >> >
> >> > Note that lock ordering as part of the application is important (e.g.
> >> > locking in same order) and that a table being accessed without an
> index
> >> > could lead to a Table-level lock, affecting the lock granularity quite
> >> > significantly and the risk of deadlocks as part of the applications.
> It
> >> > seemed like some index might have been missing for some of the columns
> >> > being
> >> > searched as part of some queries.
> >> >
> >> >
> >> > On Fri, May 1, 2009 at 10:59 AM, jsexton0 <[e-mail]> 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.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335261.html
> >> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335749.html
> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>
>

[OpenXGroup Inc.]

Derby database file

DDL files are located ininstall-dir/lib/install/databases.

Short Primer on Where the Heck is My Database on Disk?!?

Here's the first trap.  You don't have to specify the --dbhome option but Ihighly recommend always using it.

Good read......(scroll down a bit)

http://blogs.sun.com/foo/entry/mort_learns_jdbc_for_glassfish

On Fri, May 1, 2009 at 3:04 PM, jsexton0 <jsexton0@...> wrote:

Hello -

Today, I'm working on a Windows machine so no ulimit utility.
I have the same app on a linux though, and have seen the error there too.
It behaves very much the same way.

Where is the derby database file?

Thanks

OpenXGroup Inc. wrote:
>
> The EJB Container timer service potentially can get corrupted if the Derby
> database files that store timer data get out of sync. To avoid this
> problem,
> use MySQL to store the timer data.  So you may need to move the
> ejb__timer__tbl from embedded db to an external db
>
>
> Perhaps delete and re-create JDBC data source.....
>
> When you restart GlassFIsh what is your ulimit set at?
>
> restart GlassFish, type:
>
> *ulimit -n 32768
>
> bin/asadmin start-domain domain1 *
>
> http://thedata.org/guides/installers/maintenance/glassfish/utilities
>
>
> On Fri, May 1, 2009 at 12:20 PM, jsexton0 <jsexton0@...> wrote:
>
>>
>> Hello -
>>
>> I unloaded some SAs, shutdown everything on my computer, restarted
>> Glassfish
>> (it looked OK), and then reloaded the SAs one at a time and everything
>> came
>> up and runs normally.
>>
>> So it doesn't appear to be corrupted at least, it's just a problem with
>> the
>> general start up process, when everything is loaded.
>>
>> Thanks
>>
>>
>> Manfred Riem wrote:
>> >
>> > The only other thing I could recommend is to connect
>> > to the EJB timer database yourself and see if the
>> > database itself is not corrupted in anyway.
>> >
>> > Manfred
>> >
>> >> -------- Original Message --------
>> >> Subject: Re: [entpack] Derby Error Starting Glassfish
>> >> From: jsexton0 <jsexton0@...>
>> >> Date: Fri, May 01, 2009 9:49 am
>> >> To: nbentpack@...
>> >>
>> >>
>> >> Hello -
>> >>
>> >> I tried changing the max connections to 64, and the timeout to 90000
>> on
>> >> each
>> >> pool..
>> >>
>> >> __TimerPool
>> >> DerbyPool
>> >> iepseDerbyPoolNonXA
>> >> iepseDerbyPoolXA
>> >>
>> >> Still unable to startup Glassfish correctly, no change.  I do not know
>> >> were/how to set other Derby properties.  My server is
>> >> as-originally-installed with respect to the __TimerPool settings.
>> >>
>> >> I guess I'll have to try pointing it at a different database server
>> >> altogether.  I'd like to understand why this started happening
>> however,
>> >> and
>> >> I hate having to make such a drastic change to the way Glassfish comes
>> >> "out
>> >> of the box".
>> >>
>> >> I do have one timer bean in my application, but it's been working fine
>> >> for
>> >> months as other development has progressed.  Nothing in particular
>> seems
>> >> to
>> >> have caused this error to begin happening, except the application has
>> >> grown.
>> >>
>> >> Thanks
>> >>
>> >>
>> >> OpenXGroup Inc. wrote:
>> >> >
>> >> > Another thing to try- change
>> connection-validation-method="auto-commit"
>> >> to
>> >> > be "table"?
>> >> > Can you change javax.sql.ConnectionPoolDataSource to
>> >> javax.sql.DataSource?
>> >> > Or use XA datasource altogether?
>> >> >
>> >> > When you use a timer, it comes with the XA datasource access because
>> >> the
>> >> > timer instances are stored in the database. When you call your
>> method
>> >> > directly, it uses a single (non-XA) connection. And that is a big
>> >> > difference.
>> >> >
>> >> > More information about *how to diagnose a deadlock situation in
>> Derby
>> /
>> >> > Java
>> >> > DB*.
>> >> > http://wiki.apache.org/db-derby/LockDebugging
>> >> > http://db.apache.org/derby/docs/dev/devguide/cdevconcepts50894.html
>> >> >
>> >> > Note that lock ordering as part of the application is important
>> (e.g.
>> >> > locking in same order) and that a table being accessed without an
>> index
>> >> > could lead to a Table-level lock, affecting the lock granularity
>> quite
>> >> > significantly and the risk of deadlocks as part of the applications.
>> It
>> >> > seemed like some index might have been missing for some of the
>> columns
>> >> > being
>> >> > searched as part of some queries.
>> >> >
>> >> >
>> >> > 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.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335261.html
>> >> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335749.html
>> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23338191.html

Sent from the NetBeans - EntPack mailing list archive at Nabble.com.

[Manfred Riem]

For domain1 the actual Derby database files would be in

$GLASSFISH_INSTALL/domain1/lib/databases/ejbtimer

Manfred

> Hello -
>
> Today, I'm working on a Windows machine so no ulimit utility.
> I have the same app on a linux though, and have seen the error there too.
> It behaves very much the same way.
>
> Where is the derby database file?
>
> Thanks

[OpenXGroup Inc.]

Another very good read....think you will like it.

Create in a table using sql scripts that are within $ GLASSFISH_HOME / lib / install / databases

The script mysql is not present you can copy it from here:

http://programmaremobile.blogspot.com/2009/02/clustering-and-ejb-timer-eng.html

EJB Timer Service and Derby - Examine the ejbTimer database?

1) Does the directory "/usr/local/glassfish/domains/domain1/lib/databases/ejbtimer" exist ?
2) You can connect to this database using "ij" tool and check whether database is fine.
a) cd $GLASSFISH_HOME/javadb/frameworks/NetworkServer/bin
b) set DERBY_HOME to $GLASSFISH_HOME/javadb or export DERBY_HOME=$GLASSFISH_HOME/javadb
c) ij.ksh - will start 'ij' command line
d)ij > connect 'jdbc:derby:/usr/local/glassfish/domains/domain1/lib/databases/ejbtimer';
e) ij > show tables;
(must list a no. of tables along with "APP |EJB__TIMER__TBL |"
f) ij > select * from EJB__TIMER__TBL;
(select must show the contents (if any) in the table )

(2) might also throw the same exception (along with the underlying exceptions) for you, if there is any problem with the database contents. 

v3

http://docs.sun.com/app/docs/doc/820-4496/beahw?a=view

On Fri, May 1, 2009 at 3:04 PM, jsexton0 <jsexton0@...> wrote:

Hello -

Today, I'm working on a Windows machine so no ulimit utility.
I have the same app on a linux though, and have seen the error there too.
It behaves very much the same way.

Where is the derby database file?

Thanks

OpenXGroup Inc. wrote:
>
> The EJB Container timer service potentially can get corrupted if the Derby
> database files that store timer data get out of sync. To avoid this
> problem,
> use MySQL to store the timer data.  So you may need to move the
> ejb__timer__tbl from embedded db to an external db
>
>
> Perhaps delete and re-create JDBC data source.....
>
> When you restart GlassFIsh what is your ulimit set at?
>
> restart GlassFish, type:
>
> *ulimit -n 32768
>
> bin/asadmin start-domain domain1 *
>
> http://thedata.org/guides/installers/maintenance/glassfish/utilities
>
>
> On Fri, May 1, 2009 at 12:20 PM, jsexton0 <jsexton0@...> wrote:
>
>>
>> Hello -
>>
>> I unloaded some SAs, shutdown everything on my computer, restarted
>> Glassfish
>> (it looked OK), and then reloaded the SAs one at a time and everything
>> came
>> up and runs normally.
>>
>> So it doesn't appear to be corrupted at least, it's just a problem with
>> the
>> general start up process, when everything is loaded.
>>
>> Thanks
>>
>>
>> Manfred Riem wrote:
>> >
>> > The only other thing I could recommend is to connect
>> > to the EJB timer database yourself and see if the
>> > database itself is not corrupted in anyway.
>> >
>> > Manfred
>> >
>> >> -------- Original Message --------
>> >> Subject: Re: [entpack] Derby Error Starting Glassfish
>> >> From: jsexton0 <jsexton0@...>
>> >> Date: Fri, May 01, 2009 9:49 am
>> >> To: nbentpack@...
>> >>
>> >>
>> >> Hello -
>> >>
>> >> I tried changing the max connections to 64, and the timeout to 90000
>> on
>> >> each
>> >> pool..
>> >>
>> >> __TimerPool
>> >> DerbyPool
>> >> iepseDerbyPoolNonXA
>> >> iepseDerbyPoolXA
>> >>
>> >> Still unable to startup Glassfish correctly, no change.  I do not know
>> >> were/how to set other Derby properties.  My server is
>> >> as-originally-installed with respect to the __TimerPool settings.
>> >>
>> >> I guess I'll have to try pointing it at a different database server
>> >> altogether.  I'd like to understand why this started happening
>> however,
>> >> and
>> >> I hate having to make such a drastic change to the way Glassfish comes
>> >> "out
>> >> of the box".
>> >>
>> >> I do have one timer bean in my application, but it's been working fine
>> >> for
>> >> months as other development has progressed.  Nothing in particular
>> seems
>> >> to
>> >> have caused this error to begin happening, except the application has
>> >> grown.
>> >>
>> >> Thanks
>> >>
>> >>
>> >> OpenXGroup Inc. wrote:
>> >> >
>> >> > Another thing to try- change
>> connection-validation-method="auto-commit"
>> >> to
>> >> > be "table"?
>> >> > Can you change javax.sql.ConnectionPoolDataSource to
>> >> javax.sql.DataSource?
>> >> > Or use XA datasource altogether?
>> >> >
>> >> > When you use a timer, it comes with the XA datasource access because
>> >> the
>> >> > timer instances are stored in the database. When you call your
>> method
>> >> > directly, it uses a single (non-XA) connection. And that is a big
>> >> > difference.
>> >> >
>> >> > More information about *how to diagnose a deadlock situation in
>> Derby
>> /
>> >> > Java
>> >> > DB*.
>> >> > http://wiki.apache.org/db-derby/LockDebugging
>> >> > http://db.apache.org/derby/docs/dev/devguide/cdevconcepts50894.html
>> >> >
>> >> > Note that lock ordering as part of the application is important
>> (e.g.
>> >> > locking in same order) and that a table being accessed without an
>> index
>> >> > could lead to a Table-level lock, affecting the lock granularity
>> quite
>> >> > significantly and the risk of deadlocks as part of the applications.
>> It
>> >> > seemed like some index might have been missing for some of the
>> columns
>> >> > being
>> >> > searched as part of some queries.
>> >> >
>> >> >
>> >> > 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.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335261.html
>> >> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335749.html
>> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23338191.html

Sent from the NetBeans - EntPack mailing list archive at Nabble.com.

[OpenXGroup Inc.]

Resource Contention

Using P6Spy and the GlassFish Connection Pool to Trace Database Operations

http://blogs.sun.com/enterprisetechtips/entry/using_p6spy_and_the_glassfish

Using Custom MBeans to Extend the GlassFish Administration System

http://www.java-tips.org/java-ee-tips/glassfish/using-custom-mbeans-to-extend-the-glassfish-administration-s.html

Free Dev Only Edition

http://www.jinspired.com

JStack

With V3 Prelude you can now use the EJB Timer Service with the Embedded JavaDB database, as had been available in all prior releases of GlassFish and Sun Application server. 
To do so, just install JTS package from the Update Center and restart the server. You need JTS support because the __TimerPool is configured to use XA resources.

Enabling TimerService.

1. Change pool-name for the JDBC resource named jdbc/__TimerPool to point to the same connection pool as the one you are using for the rest of your data. You can do this either by editing the domain.xml file (and restarting the server), or via AdminGUI console (http://localhost:8080/admin/).

2. Start the database (or make sure it is running).

3. Deploy EJB Timer application that is located under <your-installtion>/glassfish/modules/ejb/ejb-timer-service-app-10.0-tp-2-SNAPSHOT.war. The aplication has been set up to use JPA with the default JPA provider, and to create the table on the first access.

4. Test that the TimerService has been started by accessing the following URL: http://localhost:8080/ejb-timer-service-app/timer

Using TimerService.

All EJB 3.0 Timer features are supported with the exception of injection of TimerService using @Resource annotation. You can lookup TimerService via java:comp/TimerService.

You can also send questions or comments to users@... or dev@...

dev@...

On Fri, May 1, 2009 at 3:04 PM, jsexton0 <jsexton0@...> wrote:

Hello -

Today, I'm working on a Windows machine so no ulimit utility.
I have the same app on a linux though, and have seen the error there too.
It behaves very much the same way.

Where is the derby database file?

Thanks

OpenXGroup Inc. wrote:
>
> The EJB Container timer service potentially can get corrupted if the Derby
> database files that store timer data get out of sync. To avoid this
> problem,
> use MySQL to store the timer data.  So you may need to move the
> ejb__timer__tbl from embedded db to an external db
>
>
> Perhaps delete and re-create JDBC data source.....
>
> When you restart GlassFIsh what is your ulimit set at?
>
> restart GlassFish, type:
>
> *ulimit -n 32768
>
> bin/asadmin start-domain domain1 *
>
> http://thedata.org/guides/installers/maintenance/glassfish/utilities
>
>
> On Fri, May 1, 2009 at 12:20 PM, jsexton0 <jsexton0@...> wrote:
>
>>
>> Hello -
>>
>> I unloaded some SAs, shutdown everything on my computer, restarted
>> Glassfish
>> (it looked OK), and then reloaded the SAs one at a time and everything
>> came
>> up and runs normally.
>>
>> So it doesn't appear to be corrupted at least, it's just a problem with
>> the
>> general start up process, when everything is loaded.
>>
>> Thanks
>>
>>
>> Manfred Riem wrote:
>> >
>> > The only other thing I could recommend is to connect
>> > to the EJB timer database yourself and see if the
>> > database itself is not corrupted in anyway.
>> >
>> > Manfred
>> >
>> >> -------- Original Message --------
>> >> Subject: Re: [entpack] Derby Error Starting Glassfish
>> >> From: jsexton0 <jsexton0@...>
>> >> Date: Fri, May 01, 2009 9:49 am
>> >> To: nbentpack@...
>> >>
>> >>
>> >> Hello -
>> >>
>> >> I tried changing the max connections to 64, and the timeout to 90000
>> on
>> >> each
>> >> pool..
>> >>
>> >> __TimerPool
>> >> DerbyPool
>> >> iepseDerbyPoolNonXA
>> >> iepseDerbyPoolXA
>> >>
>> >> Still unable to startup Glassfish correctly, no change.  I do not know
>> >> were/how to set other Derby properties.  My server is
>> >> as-originally-installed with respect to the __TimerPool settings.
>> >>
>> >> I guess I'll have to try pointing it at a different database server
>> >> altogether.  I'd like to understand why this started happening
>> however,
>> >> and
>> >> I hate having to make such a drastic change to the way Glassfish comes
>> >> "out
>> >> of the box".
>> >>
>> >> I do have one timer bean in my application, but it's been working fine
>> >> for
>> >> months as other development has progressed.  Nothing in particular
>> seems
>> >> to
>> >> have caused this error to begin happening, except the application has
>> >> grown.
>> >>
>> >> Thanks
>> >>
>> >>
>> >> OpenXGroup Inc. wrote:
>> >> >
>> >> > Another thing to try- change
>> connection-validation-method="auto-commit"
>> >> to
>> >> > be "table"?
>> >> > Can you change javax.sql.ConnectionPoolDataSource to
>> >> javax.sql.DataSource?
>> >> > Or use XA datasource altogether?
>> >> >
>> >> > When you use a timer, it comes with the XA datasource access because
>> >> the
>> >> > timer instances are stored in the database. When you call your
>> method
>> >> > directly, it uses a single (non-XA) connection. And that is a big
>> >> > difference.
>> >> >
>> >> > More information about *how to diagnose a deadlock situation in
>> Derby
>> /
>> >> > Java
>> >> > DB*.
>> >> > http://wiki.apache.org/db-derby/LockDebugging
>> >> > http://db.apache.org/derby/docs/dev/devguide/cdevconcepts50894.html
>> >> >
>> >> > Note that lock ordering as part of the application is important
>> (e.g.
>> >> > locking in same order) and that a table being accessed without an
>> index
>> >> > could lead to a Table-level lock, affecting the lock granularity
>> quite
>> >> > significantly and the risk of deadlocks as part of the applications.
>> It
>> >> > seemed like some index might have been missing for some of the
>> columns
>> >> > being
>> >> > searched as part of some queries.
>> >> >
>> >> >
>> >> > 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.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335261.html
>> >> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335749.html
>> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23338191.html

Sent from the NetBeans - EntPack mailing list archive at Nabble.com.

[OpenXGroup Inc.]

Should have added this as well

Glassbox

http://www.javapassion.com/j2ee/glassfish_monitoring.pdf

http://viralpatel.net/blogs/2009/03/performance-monitoring-using-glassbox.html

There is a special program called FishCAT (http://wiki.glassfish.java.net/Wiki.jsp?page=FishCAT) that one can join to become an official GlassFish tester.  Just wanted to put that out there!

On Fri, May 1, 2009 at 3:04 PM, jsexton0 <jsexton0@...> wrote:

Hello -

Today, I'm working on a Windows machine so no ulimit utility.
I have the same app on a linux though, and have seen the error there too.
It behaves very much the same way.

Where is the derby database file?

Thanks

OpenXGroup Inc. wrote:
>
> The EJB Container timer service potentially can get corrupted if the Derby
> database files that store timer data get out of sync. To avoid this
> problem,
> use MySQL to store the timer data.  So you may need to move the
> ejb__timer__tbl from embedded db to an external db
>
>
> Perhaps delete and re-create JDBC data source.....
>
> When you restart GlassFIsh what is your ulimit set at?
>
> restart GlassFish, type:
>
> *ulimit -n 32768
>
> bin/asadmin start-domain domain1 *
>
> http://thedata.org/guides/installers/maintenance/glassfish/utilities
>
>
> On Fri, May 1, 2009 at 12:20 PM, jsexton0 <jsexton0@...> wrote:
>
>>
>> Hello -
>>
>> I unloaded some SAs, shutdown everything on my computer, restarted
>> Glassfish
>> (it looked OK), and then reloaded the SAs one at a time and everything
>> came
>> up and runs normally.
>>
>> So it doesn't appear to be corrupted at least, it's just a problem with
>> the
>> general start up process, when everything is loaded.
>>
>> Thanks
>>
>>
>> Manfred Riem wrote:
>> >
>> > The only other thing I could recommend is to connect
>> > to the EJB timer database yourself and see if the
>> > database itself is not corrupted in anyway.
>> >
>> > Manfred
>> >
>> >> -------- Original Message --------
>> >> Subject: Re: [entpack] Derby Error Starting Glassfish
>> >> From: jsexton0 <jsexton0@...>
>> >> Date: Fri, May 01, 2009 9:49 am
>> >> To: nbentpack@...
>> >>
>> >>
>> >> Hello -
>> >>
>> >> I tried changing the max connections to 64, and the timeout to 90000
>> on
>> >> each
>> >> pool..
>> >>
>> >> __TimerPool
>> >> DerbyPool
>> >> iepseDerbyPoolNonXA
>> >> iepseDerbyPoolXA
>> >>
>> >> Still unable to startup Glassfish correctly, no change.  I do not know
>> >> were/how to set other Derby properties.  My server is
>> >> as-originally-installed with respect to the __TimerPool settings.
>> >>
>> >> I guess I'll have to try pointing it at a different database server
>> >> altogether.  I'd like to understand why this started happening
>> however,
>> >> and
>> >> I hate having to make such a drastic change to the way Glassfish comes
>> >> "out
>> >> of the box".
>> >>
>> >> I do have one timer bean in my application, but it's been working fine
>> >> for
>> >> months as other development has progressed.  Nothing in particular
>> seems
>> >> to
>> >> have caused this error to begin happening, except the application has
>> >> grown.
>> >>
>> >> Thanks
>> >>
>> >>
>> >> OpenXGroup Inc. wrote:
>> >> >
>> >> > Another thing to try- change
>> connection-validation-method="auto-commit"
>> >> to
>> >> > be "table"?
>> >> > Can you change javax.sql.ConnectionPoolDataSource to
>> >> javax.sql.DataSource?
>> >> > Or use XA datasource altogether?
>> >> >
>> >> > When you use a timer, it comes with the XA datasource access because
>> >> the
>> >> > timer instances are stored in the database. When you call your
>> method
>> >> > directly, it uses a single (non-XA) connection. And that is a big
>> >> > difference.
>> >> >
>> >> > More information about *how to diagnose a deadlock situation in
>> Derby
>> /
>> >> > Java
>> >> > DB*.
>> >> > http://wiki.apache.org/db-derby/LockDebugging
>> >> > http://db.apache.org/derby/docs/dev/devguide/cdevconcepts50894.html
>> >> >
>> >> > Note that lock ordering as part of the application is important
>> (e.g.
>> >> > locking in same order) and that a table being accessed without an
>> index
>> >> > could lead to a Table-level lock, affecting the lock granularity
>> quite
>> >> > significantly and the risk of deadlocks as part of the applications.
>> It
>> >> > seemed like some index might have been missing for some of the
>> columns
>> >> > being
>> >> > searched as part of some queries.
>> >> >
>> >> >
>> >> > 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.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335261.html
>> >> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23335749.html
>> Sent from the NetBeans - EntPack mailing list archive at Nabble.com.
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Derby-Error-Starting-Glassfish-tp23334048p23338191.html

Sent from the NetBeans - EntPack mailing list archive at Nabble.com.

[jsexton0]

Hello -

I seem to have reached the inescapable conclusion that Derby can not handle supporting the EJB timer service in Glassfish after the application reaches a certain point.  And the only (drastic) choice is to reconfigure Glassfish with a different database.

I only have one timer in my application, but a have been steadily adding SAs and I have 3 or 4 DB connection pools, so I guess one of those pushes it over the edge and prevents a valid start up?

It's hard to believe that something has not been overlooked here, it really just doesn't work?  Simple as that?  Anyone else want to make a suggestion?

Thanks - here is the startup exception again, just in case.

JDO74009: Bean 'TimerBean' method ejbSelectAllTimersByOwnerAndState: problems running JDOQL query with params [server, 0]
com.sun.jdo.api.persistence.support.JDODataStoreException: JDO76400: Got a JDBC SQLException while executing the SQL statement:
SQL statement<select distinct t0."TIMERID", t0."CREATIONTIMERAW", t0."LASTEXPIRATIONRAW", t0."CONTAINERID", t0."OWNERID", t0."STATE", t0."PKHASHCODE", t0."INTERVALDURATION", t0."INITIALEXPIRATIONRAW" from "EJB__TIMER__TBL" t0 where t0."OWNERID" = CAST (? AS VARCHAR(32672)) and t0."STATE" = CAST (? AS INTEGER)> with input values:java.lang.String:server, java.lang.Integer:0.
Please examine the SQLException for more information.
NestedException: java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
        at com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.throwJDOSqlException(SQLStoreManager.java:645)
        at com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:479)
        at com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:376)
        at com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:1118)
        at com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:689)
        at com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArray(QueryImpl.java:607)
        at com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersByOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
        at com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServer(TimerBean.java:709)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
        at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
        at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
        at com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvocationHandler.java:242)
        at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
        at com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:491)
        at com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactoryImpl.java:364)
        at com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.java:348)
        at com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:526)
        at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
        at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
NestedStackTrace:
java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
        at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
        at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
        at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
        at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
        at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
        at com.sun.jdo.spi.persistence.support.sqlstore.sql.ResultDesc.getResult(ResultDesc.java:490)
        at com.sun.jdo.spi.persistence.support.sqlstore.sql.generator.SelectQueryPlan.getResult(SelectQueryPlan.java:1576)
        at com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:477)
        at com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:376)
        at com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:1118)
        at com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:689)
        at com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArray(QueryImpl.java:607)
        at com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersByOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
        at com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServer(TimerBean.java:709)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
        at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
        at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
        at com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvocationHandler.java:242)
        at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
        at com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:491)
        at com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactoryImpl.java:364)
        at com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.java:348)
        at com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:526)
        at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
        at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
Caused by: java.sql.SQLException: A lock could not be obtained within the time requested
        at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
        at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
        ... 38 more

[Manfred Riem]

Hi there,

Have you tried executing the query against that database
yourself?

Manfred

> Hello -
>
> I seem to have reached the inescapable conclusion that Derby can not handle
> supporting the EJB timer service in Glassfish after the application reaches
> a certain point.  And the only (drastic) choice is to reconfigure Glassfish
> with a different database.
>
> I only have one timer in my application, but a have been steadily adding SAs
> and I have 3 or 4 DB connection pools, so I guess one of those pushes it
> over the edge and prevents a valid start up?
>
> It's hard to believe that something has not been overlooked here, it really
> just doesn't work?  Simple as that?  Anyone else want to make a suggestion?
>
> Thanks - here is the startup exception again, just in case.
>
> JDO74009: Bean 'TimerBean' method ejbSelectAllTimersByOwnerAndState:
> problems running JDOQL query with params [server, 0]
> com.sun.jdo.api.persistence.support.JDODataStoreException: JDO76400: Got a
> JDBC SQLException while executing the SQL statement:
> SQL statement<select distinct t0."TIMERID", t0."CREATIONTIMERAW",
> t0."LASTEXPIRATIONRAW", t0."CONTAINERID", t0."OWNERID", t0."STATE",
> t0."PKHASHCODE", t0."INTERVALDURATION", t0."INITIALEXPIRATIONRAW" from
> "EJB__TIMER__TBL" t0 where t0."OWNERID" = CAST (? AS VARCHAR(32672)) and
> t0."STATE" = CAST (? AS INTEGER)> with input values:java.lang.String:server,
> java.lang.Integer:0.
> Please examine the SQLException for more information.
> NestedException: java.sql.SQLTransactionRollbackException: A lock could not
> be obtained within the time requested
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.throwJDOSqlException(SQLStoreManager.java:645)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:479)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:376)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:1118)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:689)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArray(QueryImpl.java:607)
>         at
> com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersByOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
>         at
> com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServer(TimerBean.java:709)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
>         at
> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
>         at
> com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
>         at
> com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvocationHandler.java:242)
>         at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
>         at
> com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:491)
>         at
> com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactoryImpl.java:364)
>         at
> com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.java:348)
>         at
> com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:526)
>         at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
>         at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
> NestedStackTrace:
> java.sql.SQLTransactionRollbackException: A lock could not be obtained
> within the time requested
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
>         at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
>         at
> org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.sql.ResultDesc.getResult(ResultDesc.java:490)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.sql.generator.SelectQueryPlan.getResult(SelectQueryPlan.java:1576)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:477)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:376)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:1118)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:689)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArray(QueryImpl.java:607)
>         at
> com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersByOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
>         at
> com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServer(TimerBean.java:709)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
>         at
> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
>         at
> com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
>         at
> com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvocationHandler.java:242)
>         at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
>         at
> com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:491)
>         at
> com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactoryImpl.java:364)
>         at
> com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.java:348)
>         at
> com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:526)
>         at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
>         at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
> Caused by: java.sql.SQLException: A lock could not be obtained within the
> time requested
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
> Source)
>         ... 38 more

[jsexton0]

I get "no suitable driver" on the connect command.  What am I missing there?

This does in fact come up if I undeploy a few things, startup Glassfish, and re-deploy after it has finished it's start process.  But if, and only if, my full application is loaded when Glassfish start, then the EJB timer service fails to start due to the time-out selecting from Derby.  

Thanks

Manfred Riem wrote:

Hi there,

Have you tried executing the query against that database
yourself?

Manfred

> Hello -
>
> I seem to have reached the inescapable conclusion that Derby can not handle
> supporting the EJB timer service in Glassfish after the application reaches
> a certain point.  And the only (drastic) choice is to reconfigure Glassfish
> with a different database.
>
> I only have one timer in my application, but a have been steadily adding SAs
> and I have 3 or 4 DB connection pools, so I guess one of those pushes it
> over the edge and prevents a valid start up?
>
> It's hard to believe that something has not been overlooked here, it really
> just doesn't work?  Simple as that?  Anyone else want to make a suggestion?
>
> Thanks - here is the startup exception again, just in case.
>
> JDO74009: Bean 'TimerBean' method ejbSelectAllTimersByOwnerAndState:
> problems running JDOQL query with params [server, 0]
> com.sun.jdo.api.persistence.support.JDODataStoreException: JDO76400: Got a
> JDBC SQLException while executing the SQL statement:
> SQL statement<select distinct t0."TIMERID", t0."CREATIONTIMERAW",
> t0."LASTEXPIRATIONRAW", t0."CONTAINERID", t0."OWNERID", t0."STATE",
> t0."PKHASHCODE", t0."INTERVALDURATION", t0."INITIALEXPIRATIONRAW" from
> "EJB__TIMER__TBL" t0 where t0."OWNERID" = CAST (? AS VARCHAR(32672)) and
> t0."STATE" = CAST (? AS INTEGER)> with input values:java.lang.String:server,
> java.lang.Integer:0.
> Please examine the SQLException for more information.
> NestedException: java.sql.SQLTransactionRollbackException: A lock could not
> be obtained within the time requested
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.throwJDOSqlException(SQLStoreManager.java:645)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:479)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:376)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:1118)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:689)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArray(QueryImpl.java:607)
>         at
> com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersByOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
>         at
> com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServer(TimerBean.java:709)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
>         at
> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
>         at
> com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
>         at
> com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvocationHandler.java:242)
>         at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
>         at
> com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:491)
>         at
> com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactoryImpl.java:364)
>         at
> com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.java:348)
>         at
> com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:526)
>         at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
>         at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
> NestedStackTrace:
> java.sql.SQLTransactionRollbackException: A lock could not be obtained
> within the time requested
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
>         at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
>         at
> org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.sql.ResultDesc.getResult(ResultDesc.java:490)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.sql.generator.SelectQueryPlan.getResult(SelectQueryPlan.java:1576)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:477)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:376)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:1118)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:689)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArray(QueryImpl.java:607)
>         at
> com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersByOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
>         at
> com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServer(TimerBean.java:709)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
>         at
> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
>         at
> com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
>         at
> com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvocationHandler.java:242)
>         at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
>         at
> com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:491)
>         at
> com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactoryImpl.java:364)
>         at
> com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.java:348)
>         at
> com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:526)
>         at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
>         at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
> Caused by: java.sql.SQLException: A lock could not be obtained within the
> time requested
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
> Source)
>         ... 38 more

[Gavin Ross(v)]

Please supply a copy of your domain.xml file. There may be a conflict in
your glassfish setup as I am running glassfish very well with upto 8
connection pools in a production environment without any issues.

Gavin Ross
Preferred Partner : The Bluebox
Cell: 0837038110
Email: gavin@...


-----Original Message-----
From: jsexton0 [mailto:jsexton0@...]
Sent: 04 May 2009 05:40 PM
To: nbentpack@...
Subject: Re: [entpack] Derby Error Starting Glassfish



Hello -

I seem to have reached the inescapable conclusion that Derby can not handle
supporting the EJB timer service in Glassfish after the application reaches
a certain point.  And the only (drastic) choice is to reconfigure Glassfish
with a different database.

I only have one timer in my application, but a have been steadily adding SAs
and I have 3 or 4 DB connection pools, so I guess one of those pushes it
over the edge and prevents a valid start up?

It's hard to believe that something has not been overlooked here, it really
just doesn't work?  Simple as that?  Anyone else want to make a suggestion?

Thanks - here is the startup exception again, just in case.

JDO74009: Bean 'TimerBean' method ejbSelectAllTimersByOwnerAndState:
problems running JDOQL query with params [server, 0]
com.sun.jdo.api.persistence.support.JDODataStoreException: JDO76400: Got a
JDBC SQLException while executing the SQL statement: SQL statement<select
distinct t0."TIMERID", t0."CREATIONTIMERAW", t0."LASTEXPIRATIONRAW",
t0."CONTAINERID", t0."OWNERID", t0."STATE", t0."PKHASHCODE",
t0."INTERVALDURATION", t0."INITIALEXPIRATIONRAW" from "EJB__TIMER__TBL" t0
where t0."OWNERID" = CAST (? AS VARCHAR(32672)) and t0."STATE" = CAST (? AS
INTEGER)> with input values:java.lang.String:server, java.lang.Integer:0.
Please examine the SQLException for more information.
NestedException: java.sql.SQLTransactionRollbackException: A lock could not
be obtained within the time requested
        at
com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.throwJDOSqlExce
ption(SQLStoreManager.java:645)
        at
com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQ
LStoreManager.java:479)
        at
com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLSto
reManager.java:376)
        at
com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.ret
rieve(PersistenceManagerImpl.java:1118)
        at
com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(Query
Impl.java:689)
        at
com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArra
y(QueryImpl.java:607)
        at
com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersB
yOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
        at
com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServ
er(TimerBean.java:709)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecu
rityManager.java:1067)
        at
com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
        at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.ja
va:2895)
        at
com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvo
cationHandler.java:242)
        at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
        at
com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:49
1)
        at
com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactor
yImpl.java:364)
        at
com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.
java:348)
        at
com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:5
26)
        at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
        at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
NestedStackTrace:
java.sql.SQLTransactionRollbackException: A lock could not be obtained
within the time requested
        at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
Source)
        at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
Source)
        at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknow
n
Source)
        at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
Source)
        at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
        at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
        at
org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown
Source)
        at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown
Source)
        at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
        at
com.sun.jdo.spi.persistence.support.sqlstore.sql.ResultDesc.getResult(Result
Desc.java:490)
        at
com.sun.jdo.spi.persistence.support.sqlstore.sql.generator.SelectQueryPlan.g
etResult(SelectQueryPlan.java:1576)
        at
com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQ
LStoreManager.java:477)
        at
com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLSto
reManager.java:376)
        at
com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.ret
rieve(PersistenceManagerImpl.java:1118)
        at
com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(Query
Impl.java:689)
        at
com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArra
y(QueryImpl.java:607)
        at
com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersB
yOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
        at
com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServ
er(TimerBean.java:709)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecu
rityManager.java:1067)
        at
com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
        at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.ja
va:2895)
        at
com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvo
cationHandler.java:242)
        at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
        at
com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:49
1)
        at
com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactor
yImpl.java:364)
        at
com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.
java:348)
        at
com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:5
26)
        at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
        at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
Caused by: java.sql.SQLException: A lock could not be obtained within the
time requested
        at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source)
        at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossD
RDA(Unknown
Source)
        ... 38 more



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


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.287 / Virus Database: 270.12.15/2093 - Release Date: 05/02/09
14:23:00

[jsexton0]

Hello again...

I got connected using newer scripts in /javadb/bin rather than /frameworks/NewtworkServer/bin.
It's a little show to connect, and "show tables" seems to hang - with Glassfish not running.


I get "no suitable driver" on the connect command.  What am I missing there?

This does in fact come up if I undeploy a few things, startup Glassfish, and re-deploy after it has finished it's start process.  But if, and only if, my full application is loaded when Glassfish start, then the EJB timer service fails to start due to the time-out selecting from Derby.  

Thanks

Manfred Riem wrote:

Hi there,

Have you tried executing the query against that database
yourself?

Manfred

> Hello -
>
> I seem to have reached the inescapable conclusion that Derby can not handle
> supporting the EJB timer service in Glassfish after the application reaches
> a certain point.  And the only (drastic) choice is to reconfigure Glassfish
> with a different database.
>
> I only have one timer in my application, but a have been steadily adding SAs
> and I have 3 or 4 DB connection pools, so I guess one of those pushes it
> over the edge and prevents a valid start up?
>
> It's hard to believe that something has not been overlooked here, it really
> just doesn't work?  Simple as that?  Anyone else want to make a suggestion?
>
> Thanks - here is the startup exception again, just in case.
>
> JDO74009: Bean 'TimerBean' method ejbSelectAllTimersByOwnerAndState:
> problems running JDOQL query with params [server, 0]
> com.sun.jdo.api.persistence.support.JDODataStoreException: JDO76400: Got a
> JDBC SQLException while executing the SQL statement:
> SQL statement<select distinct t0."TIMERID", t0."CREATIONTIMERAW",
> t0."LASTEXPIRATIONRAW", t0."CONTAINERID", t0."OWNERID", t0."STATE",
> t0."PKHASHCODE", t0."INTERVALDURATION", t0."INITIALEXPIRATIONRAW" from
> "EJB__TIMER__TBL" t0 where t0."OWNERID" = CAST (? AS VARCHAR(32672)) and
> t0."STATE" = CAST (? AS INTEGER)> with input values:java.lang.String:server,
> java.lang.Integer:0.
> Please examine the SQLException for more information.
> NestedException: java.sql.SQLTransactionRollbackException: A lock could not
> be obtained within the time requested
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.throwJDOSqlException(SQLStoreManager.java:645)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:479)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:376)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:1118)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:689)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArray(QueryImpl.java:607)
>         at
> com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersByOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
>         at
> com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServer(TimerBean.java:709)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
>         at
> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
>         at
> com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
>         at
> com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvocationHandler.java:242)
>         at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
>         at
> com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:491)
>         at
> com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactoryImpl.java:364)
>         at
> com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.java:348)
>         at
> com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:526)
>         at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
>         at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
> NestedStackTrace:
> java.sql.SQLTransactionRollbackException: A lock could not be obtained
> within the time requested
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
>         at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
>         at
> org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.sql.ResultDesc.getResult(ResultDesc.java:490)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.sql.generator.SelectQueryPlan.getResult(SelectQueryPlan.java:1576)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:477)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:376)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:1118)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:689)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArray(QueryImpl.java:607)
>         at
> com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersByOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
>         at
> com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServer(TimerBean.java:709)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
>         at
> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
>         at
> com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
>         at
> com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvocationHandler.java:242)
>         at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
>         at
> com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:491)
>         at
> com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactoryImpl.java:364)
>         at
> com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.java:348)
>         at
> com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:526)
>         at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
>         at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
> Caused by: java.sql.SQLException: A lock could not be obtained within the
> time requested
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
> Source)
>         ... 38 more

[jsexton0]

Here is domain.xml, thanks.  It's reassuring that you're not seeing issues like this.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE domain PUBLIC "-//Sun Microsystems Inc.//DTD Application Server 9.1 Domain//EN" "http://www.sun.com/software/appserver/dtds/sun-domain_1_3.dtd">
<!--
   Copyright 1997-2007 Sun Microsystems, Inc.  All rights reserved.
   Use is subject to license terms.
-->
<!-- Generated from default-domain.xml.template -->
<!-- Avoid manual edits of this file. Run "asadmin verify-domain-xml" otherwise.-->
<domain application-root="${com.sun.aas.instanceRoot}/applications" log-root="${com.sun.aas.instanceRoot}/logs">
  <applications>
    <j2ee-application availability-enabled="false" directory-deployed="false" enabled="true" java-web-start-enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-apps/MEjbApp" name="MEjbApp" object-type="system-all"/>
    <j2ee-application availability-enabled="false" directory-deployed="false" enabled="true" java-web-start-enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-apps/__ejb_container_timer_app" name="__ejb_container_timer_app" object-type="system-all"/>
    <j2ee-application availability-enabled="false" directory-deployed="false" enabled="true" java-web-start-enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-apps/__JWSappclients" name="__JWSappclients" object-type="system-all"/>
    <j2ee-application availability-enabled="false" directory-deployed="true" enabled="true" java-web-start-enabled="true" location="U:/Public/work/CMS/CMS_TIMER_EA/dist/gfdeploy" name="CMS_TIMER_EA" object-type="user"/>
    <ejb-module availability-enabled="false" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/CMS_PinChange_SA-CMS_PinChange_EJB" name="CMS_PinChange_SA-CMS_PinChange_EJB" object-type="user">
      <property name="externally-managed" value="true"/>
    </ejb-module>
    <ejb-module availability-enabled="false" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/CMS_CardHolder_SA-CMS_CardHolder_EJB" name="CMS_CardHolder_SA-CMS_CardHolder_EJB" object-type="user">
      <property name="externally-managed" value="true"/>
    </ejb-module>
    <ejb-module availability-enabled="false" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/MSG_SA-MSG_EJB" name="MSG_SA-MSG_EJB" object-type="user">
      <property name="externally-managed" value="true"/>
    </ejb-module>
    <ejb-module availability-enabled="false" directory-deployed="true" enabled="true" location="U:/Public/work/CMS/CMS_Custom_EJB/build/jar" name="CMS_Custom_EJB" object-type="user"/>
    <ejb-module availability-enabled="false" directory-deployed="true" enabled="true" location="U:/Public/work/CMS/CMS_CATSA_EJB/build/jar" name="CMS_CATSA_EJB" object-type="user"/>
    <ejb-module availability-enabled="false" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/LST_SA-LST_EJB" name="LST_SA-LST_EJB" object-type="user">
      <property name="externally-managed" value="true"/>
    </ejb-module>
    <ejb-module availability-enabled="false" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/CMS_Card_SA-CMS_Card_EJB" name="CMS_Card_SA-CMS_Card_EJB" object-type="user">
      <property name="externally-managed" value="true"/>
    </ejb-module>
    <ejb-module availability-enabled="false" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/CMS_Print_SA-CMS_Print_EJB" name="CMS_Print_SA-CMS_Print_EJB" object-type="user">
      <property name="externally-managed" value="true"/>
    </ejb-module>
    <ejb-module availability-enabled="false" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/CMS_AuditTrail_SA-CMS_AuditLog_EJB" name="CMS_AuditTrail_SA-CMS_AuditLog_EJB" object-type="user">
      <property name="externally-managed" value="true"/>
    </ejb-module>
    <ejb-module availability-enabled="false" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/CMS_CATSA_SA-CMS_CATSA_EJB" name="CMS_CATSA_SA-CMS_CATSA_EJB" object-type="user">
      <property name="externally-managed" value="true"/>
    </ejb-module>
    <ejb-module availability-enabled="false" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/ConfigurationManagerSA-ConfigurationManagerEJB" name="ConfigurationManagerSA-ConfigurationManagerEJB" object-type="user">
      <property name="externally-managed" value="true"/>
    </ejb-module>
    <ejb-module availability-enabled="false" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/CMS_SA-CMS_EJB" name="CMS_SA-CMS_EJB" object-type="user">
      <property name="externally-managed" value="true"/>
    </ejb-module>
    <web-module availability-enabled="false" context-root="/web1" directory-deployed="true" enabled="true" location="${com.sun.aas.installRoot}/lib/install/applications/adminapp/adminapp_war" name="adminapp" object-type="system-admin">
      <!-- System Web Module - DO NOT DELETE! -->
    </web-module>
    <web-module availability-enabled="false" context-root="" directory-deployed="true" enabled="true" location="${com.sun.aas.installRoot}/lib/install/applications/admingui/adminGUI_war" name="admingui" object-type="system-admin">
      <!-- System Web Module - DO NOT DELETE! -->
    </web-module>
    <web-module availability-enabled="false" context-root="/__wstx-services" directory-deployed="true" enabled="true" location="${com.sun.aas.installRoot}/lib/install/applications/wstx-services" name="WSTXServices" object-type="system-all"/>
    <lifecycle-module class-name="com.sun.jbi.framework.sun.SunASJBIBootstrap" classpath="${com.sun.aas.installRoot}/jbi/lib/jbi_framework.jar" enabled="true" is-failure-fatal="false" name="JBIFramework" object-type="system-all">
      <description>"JBI Framework LifecycleModule"</description>
      <property name="com.sun.jbi.home" value="${com.sun.aas.installRoot}/jbi"/>
    </lifecycle-module>
    <lifecycle-module class-name="com.sun.xml.ws.transport.tcp.server.glassfish.WSTCPLifeCycleModule" classpath="${com.sun.aas.installRoot}/lib/webservices-rt.jar" enabled="true" is-failure-fatal="false" name="WSTCPConnectorLCModule" object-type="system-all"/>
    <web-module availability-enabled="false" context-root="portletdriver" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/portletdriver" name="portletdriver" object-type="user"/>
    <web-module availability-enabled="false" context-root="/cam" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/cam" name="cam" object-type="user"/>
    <web-module availability-enabled="false" context-root="/camBpelPlugin" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/camBpelPlugin" name="camBpelPlugin" object-type="user"/>
    <web-module availability-enabled="false" context-root="/aspects" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/aspects" name="aspects" object-type="user"/>
    <web-module availability-enabled="false" context-root="amserver" directory-deployed="false" enabled="true" location="${com.sun.aas.instanceRoot}/applications/j2ee-modules/amserver" name="amserver" object-type="user"/>
  </applications>
  <resources>
    <jdbc-resource enabled="true" jndi-name="jdbc/sample" object-type="user" pool-name="SamplePool"/>
    <custom-resource enabled="true" factory-class="com.iwsinc.factory.StringFactory" jndi-name="ConfigurationManagerEncryptionPassword" object-type="user" res-type="java.lang.String">
      <property name="string" value="pancakeboots"/>
    </custom-resource>
    <custom-resource enabled="true" factory-class="com.iwsinc.factory.StringFactory" jndi-name="ConfigurationManagerEncryptionSalt" object-type="user" res-type="java.lang.String">
      <property name="string" value="Testingu"/>
    </custom-resource>
    <custom-resource enabled="true" factory-class="com.iwsinc.factory.StringFactory" jndi-name="ConfigurationManagerFileLocation" object-type="user" res-type="java.lang.String">
      <property name="string" value="C:\EPICMS\"/>
    </custom-resource>
    <jdbc-resource enabled="true" jndi-name="jdbc/__TimerPool" object-type="system-admin" pool-name="__TimerPool"/>
    <jdbc-resource enabled="true" jndi-name="jdbc/__CallFlowPool" object-type="system-all" pool-name="__CallFlowPool"/>
    <jdbc-resource enabled="true" jndi-name="jdbc/__defaultDS" object-type="user" pool-name="DerbyPool"/>
    <jdbc-resource enabled="true" jndi-name="jdbc/__default" object-type="user" pool-name="DerbyPool"/>
    <jdbc-resource enabled="true" jndi-name="jdbc/__workflow" object-type="user" pool-name="WorkflowPool"/>
    <jdbc-resource enabled="true" jndi-name="jdbc/iepseDerbyNonXA" object-type="user" pool-name="iepseDerbyPoolNonXA"/>
    <jdbc-resource enabled="true" jndi-name="jdbc/iepseDerbyXA" object-type="user" pool-name="iepseDerbyPoolXA"/>
    <jdbc-resource enabled="true" jndi-name="jdbc/SQLExpress" object-type="user" pool-name="SQLExpress">
      <description>CMS Database</description>
    </jdbc-resource>
    <jdbc-resource enabled="true" jndi-name="jdbc/MasterDB" object-type="user" pool-name="MasterDB">
      <description>CMS Master Database</description>
    </jdbc-resource>
    <jdbc-resource enabled="true" jndi-name="jdbc/CMSAudit" object-type="user" pool-name="CMSAudit">
      <description>CMS Audit</description>
    </jdbc-resource>
    <jdbc-resource enabled="true" jndi-name="jdbc/CIDDB" object-type="user" pool-name="CIDDB">
      <description>CID DB</description>
    </jdbc-resource>
    <jdbc-resource enabled="true" jndi-name="jdbc/RADDB" object-type="user" pool-name="RADDB">
      <description>RAD DB</description>
    </jdbc-resource>
    <admin-object-resource enabled="true" jndi-name="jms/cmsTopic" object-type="user" res-adapter="jmsra" res-type="javax.jms.Topic">
      <description>CMS JMS Topic</description>
      <property name="Name" value="CMSTopic"/>
    </admin-object-resource>
    <connector-resource enabled="true" jndi-name="jms/CMSTopicFactory" object-type="user" pool-name="jms/CMSTopicFactory">
      <description>CMS JMS Topic Connection Factory</description>
    </connector-resource>
    <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="org.apache.derby.jdbc.EmbeddedXADataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="__CallFlowPool" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.XADataSource" statement-timeout-in-seconds="-1" steady-pool-size="8" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <property name="databaseName" value="${com.sun.aas.instanceRoot}/lib/databases/sun-callflow"/>
      <property name="connectionAttributes" value=";create=true"/>
    </jdbc-connection-pool>
    <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="2" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="org.apache.derby.jdbc.EmbeddedXADataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="64" max-wait-time-in-millis="240000" name="__TimerPool" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.XADataSource" statement-timeout-in-seconds="-1" steady-pool-size="10" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <property name="databaseName" value="${com.sun.aas.instanceRoot}/lib/databases/ejbtimer"/>
    </jdbc-connection-pool>
    <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="org.apache.derby.jdbc.ClientDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="DerbyPool" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.DataSource" statement-timeout-in-seconds="-1" steady-pool-size="8" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <property name="connectionAttributes" value=";create=true"/>
      <property name="serverName" value="localhost"/>
      <property name="DatabaseName" value="sample"/>
      <property name="PortNumber" value="1527"/>
      <property name="User" value="app"/>
      <property name="Password" value="app"/>
    </jdbc-connection-pool>
    <jdbc-connection-pool allow-non-component-callers="true" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="org.apache.derby.jdbc.ClientDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="WorkflowPool" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.DataSource" statement-timeout-in-seconds="-1" steady-pool-size="8" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <property name="password" value="WORKFLOW"/>
      <property name="connectionAttributes" value=";create=true"/>
      <property name="databaseName" value="WORKFLOWDB"/>
      <property name="user" value="WORKFLOW"/>
      <property name="serverName" value="localhost"/>
      <property name="portNumber" value="1527"/>
    </jdbc-connection-pool>
    <jdbc-connection-pool allow-non-component-callers="true" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="org.apache.derby.jdbc.ClientDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="false" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="iepseDerbyPoolNonXA" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.DataSource" statement-timeout-in-seconds="-1" steady-pool-size="8" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <property name="connectionAttributes" value=";create=true"/>
      <property name="PortNumber" value="1527"/>
      <property name="Password" value="iepseDB"/>
      <property name="DatabaseName" value="iepseDB"/>
      <property name="serverName" value="localhost"/>
      <property name="User" value="iepseDB"/>
    </jdbc-connection-pool>
    <jdbc-connection-pool allow-non-component-callers="true" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="org.apache.derby.jdbc.ClientXADataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="false" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="iepseDerbyPoolXA" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.XADataSource" statement-timeout-in-seconds="-1" steady-pool-size="8" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <property name="connectionAttributes" value=";create=true"/>
      <property name="PortNumber" value="1527"/>
      <property name="Password" value="iepseDB"/>
      <property name="DatabaseName" value="iepseDB"/>
      <property name="serverName" value="localhost"/>
      <property name="User" value="iepseDB"/>
    </jdbc-connection-pool>
    <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.microsoft.sqlserver.jdbc.SQLServerConnectionPoolDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="false" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="64" max-wait-time-in-millis="60000" name="SQLExpress" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="2" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <description>SQL Server Express</description>
      <property name="databaseName" value="EpiCms"/>
      <property name="serverName" value="localhost\SQLEXPRESS"/>
      <property name="User" value="EPICMS"/>
      <property name="Password" value="ImageWare1!"/>
    </jdbc-connection-pool>
    <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.microsoft.sqlserver.jdbc.SQLServerConnectionPoolDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="false" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="MasterDB" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="1" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <description>CMS Master DB</description>
      <property name="User" value="EPICMS"/>
      <property name="databaseName" value="MasterEpiCms"/>
      <property name="Password" value="ImageWare1!"/>
      <property name="serverName" value="localhost\SQLExpress"/>
    </jdbc-connection-pool>
    <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.microsoft.sqlserver.jdbc.SQLServerConnectionPoolDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="false" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="64" max-wait-time-in-millis="60000" name="CMSAudit" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="2" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <description>CMS Audit JDBC Connection Pool</description>
      <property name="user" value="EPICMS"/>
      <property name="password" value="ImageWare1!"/>
      <property name="databaseName" value="EpiCms"/>
      <property name="serverName" value="localhost\SQLEXPRESS"/>
    </jdbc-connection-pool>
    <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.microsoft.sqlserver.jdbc.SQLServerConnectionPoolDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="false" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="CIDDB" non-transactional-connections="true" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="1" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <description>CID DB</description>
      <property name="user" value="EPICMS"/>
      <property name="password" value="ImageWare1!"/>
      <property name="databaseName" value="CID"/>
      <property name="serverName" value="localhost\SQLEXPRESS"/>
    </jdbc-connection-pool>
    <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.microsoft.sqlserver.jdbc.SQLServerConnectionPoolDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="false" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="RADDB" non-transactional-connections="true" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="1" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <description>RAD DB</description>
      <property name="databaseName" value="RAD"/>
      <property name="serverName" value="localhost\SQLEXPRESS"/>
      <property name="user" value="EPICMS"/>
      <property name="password" value="ImageWare1!"/>
    </jdbc-connection-pool>
    <connector-connection-pool associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-definition-name="javax.jms.TopicConnectionFactory" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="true" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="jms/CMSTopicFactory" pool-resize-quantity="2" resource-adapter-name="jmsra" steady-pool-size="8" validate-atmost-once-period-in-seconds="0"/>
    <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="org.apache.derby.jdbc.ClientDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="SamplePool" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.DataSource" statement-timeout-in-seconds="-1" steady-pool-size="8" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
      <property name="DatabaseName" value="sample"/>
      <property name="User" value="app"/>
      <property name="Password" value="app"/>
      <property name="URL" value="jdbc:derby://localhost:1527/sample"/>
      <property name="PortNumber" value="1527"/>
      <property name="serverName" value="localhost"/>
    </jdbc-connection-pool>
  </resources>
  <configs>
    <config dynamic-reconfiguration-enabled="true" name="server-config">
      <http-service>
        <access-log format="%client.name% %auth-user-name% %datetime% %request% %status% %response.length%" rotation-enabled="true" rotation-interval-in-minutes="15" rotation-policy="time" rotation-suffix="yyyy-MM-dd"/>
        <http-listener acceptor-threads="1" address="0.0.0.0" blocking-enabled="false" default-virtual-server="server" enabled="true" family="inet" id="http-listener-1" port="8080" security-enabled="false" server-name="" xpowered-by="true">
          <property name="proxiedProtocols" value="ws/tcp"/>
        </http-listener>
        <http-listener acceptor-threads="1" address="0.0.0.0" blocking-enabled="false" default-virtual-server="server" enabled="true" family="inet" id="http-listener-2" port="8181" security-enabled="true" server-name="" xpowered-by="true">
          <ssl cert-nickname="s1as" client-auth-enabled="false" ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true" tls-rollback-enabled="true"/>
        </http-listener>
        <http-listener acceptor-threads="1" address="0.0.0.0" blocking-enabled="false" default-virtual-server="__asadmin" enabled="true" family="inet" id="admin-listener" port="4848" security-enabled="false" server-name="" xpowered-by="true"/>
        <virtual-server hosts="${com.sun.aas.hostName}" http-listeners="http-listener-1,http-listener-2" id="server" log-file="${com.sun.aas.instanceRoot}/logs/server.log" state="on">
          <property name="docroot" value="${com.sun.aas.instanceRoot}/docroot"/>
          <property name="accesslog" value="${com.sun.aas.instanceRoot}/logs/access"/>
          <property name="sso-enabled" value="true"/>
        </virtual-server>
        <virtual-server hosts="${com.sun.aas.hostName}" http-listeners="admin-listener" id="__asadmin" log-file="${com.sun.aas.instanceRoot}/logs/server.log" state="on">
          <property name="docroot" value="${com.sun.aas.instanceRoot}/docroot"/>
          <property name="accesslog" value="${com.sun.aas.instanceRoot}/logs/access"/>
          <property name="sso-enabled" value="true"/>
        </virtual-server>
        <request-processing header-buffer-length-in-bytes="8192" initial-thread-count="2" request-timeout-in-seconds="30" thread-count="5" thread-increment="1"/>
        <keep-alive max-connections="250" thread-count="1" timeout-in-seconds="30"/>
        <connection-pool max-pending-count="4096" queue-size-in-bytes="4096" receive-buffer-size-in-bytes="8192" send-buffer-size-in-bytes="8192"/>
        <http-protocol default-response-type="AttributeDeprecated" default-type="text/html; charset=iso-8859-1" dns-lookup-enabled="false" forced-response-type="AttributeDeprecated" forced-type="text/html; charset=iso-8859-1" ssl-enabled="true" version="HTTP/1.1"/>
        <http-file-cache file-caching-enabled="false" file-transmission-enabled="false" globally-enabled="false" hash-init-size="0" max-age-in-seconds="30" max-files-count="1024" medium-file-size-limit-in-bytes="537600" medium-file-space-in-bytes="10485760" small-file-size-limit-in-bytes="2048" small-file-space-in-bytes="1048576"/>
        <property name="accessLoggingEnabled" value="false"/>
      </http-service>
      <iiop-service client-authentication-required="false">
        <orb max-connections="1024" message-fragment-size="1024" use-thread-pool-ids="thread-pool-1"/>
        <iiop-listener address="0.0.0.0" enabled="true" id="orb-listener-1" port="3700" security-enabled="false"/>
        <iiop-listener address="0.0.0.0" enabled="true" id="SSL" port="3820" security-enabled="true">
          <ssl cert-nickname="s1as" client-auth-enabled="false" ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true" tls-rollback-enabled="true"/>
        </iiop-listener>
        <iiop-listener address="0.0.0.0" enabled="true" id="SSL_MUTUALAUTH" port="3920" security-enabled="true">
          <ssl cert-nickname="s1as" client-auth-enabled="true" ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true" tls-rollback-enabled="true"/>
        </iiop-listener>
      </iiop-service>
      <admin-service system-jmx-connector-name="system" type="das-and-server">
        <!-- The JSR 160 "system-jmx-connector" -->
        <jmx-connector accept-all="false" address="0.0.0.0" auth-realm-name="admin-realm" enabled="true" name="system" port="8686" protocol="rmi_jrmp" security-enabled="false">
          <ssl cert-nickname="s1as" client-auth-enabled="false" ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true" tls-rollback-enabled="true"/>
        </jmx-connector>
        <!-- The JSR 160 "system-jmx-connector" -->
        <das-config admin-session-timeout-in-minutes="60" autodeploy-dir="${com.sun.aas.instanceRoot}/autodeploy" autodeploy-enabled="true" autodeploy-jsp-precompilation-enabled="false" autodeploy-polling-interval-in-seconds="2" autodeploy-verifier-enabled="false" deploy-xml-validation="full" dynamic-reload-enabled="true" dynamic-reload-poll-interval-in-seconds="2"/>
      </admin-service>
      <web-container>
        <session-config>
          <session-manager>
            <manager-properties/>
            <store-properties/>
          </session-manager>
          <session-properties/>
        </session-config>
      </web-container>
      <ejb-container cache-idle-timeout-in-seconds="600" cache-resize-quantity="32" commit-option="B" max-cache-size="512" max-pool-size="128" pool-idle-timeout-in-seconds="600" pool-resize-quantity="8" removal-timeout-in-seconds="5400" session-store="${com.sun.aas.instanceRoot}/session-store" steady-pool-size="0" victim-selection-policy="nru">
        <ejb-timer-service max-redeliveries="1" minimum-delivery-interval-in-millis="7000" redelivery-interval-internal-in-millis="5000"/>
      </ejb-container>
      <mdb-container idle-timeout-in-seconds="600" max-pool-size="32" pool-resize-quantity="8" steady-pool-size="0"/>
      <jms-service addresslist-behavior="random" addresslist-iterations="3" default-jms-host="default_JMS_host" init-timeout-in-seconds="60" reconnect-attempts="3" reconnect-enabled="true" reconnect-interval-in-seconds="5" type="LOCAL">
        <jms-host admin-password="admin" admin-user-name="admin" host="iws03box1.iwsinc.com" name="default_JMS_host" port="7676"/>
      </jms-service>
      <log-service alarms="false" file="${com.sun.aas.instanceRoot}/logs/server.log" log-rotation-limit-in-bytes="4000000" log-rotation-timelimit-in-minutes="0" log-to-console="false" retain-error-statistics-for-hours="5" use-system-logging="false">
        <module-log-levels admin="INFO" classloader="INFO" cmp="INFO" cmp-container="INFO" configuration="INFO" connector="INFO" corba="INFO" deployment="INFO" ejb-container="INFO" group-management-service="INFO" javamail="INFO" jaxr="INFO" jaxrpc="INFO" jdo="INFO" jms="INFO" jta="INFO" jts="INFO" management-event="INFO" mdb-container="INFO" naming="INFO" node-agent="INFO" resource-adapter="INFO" root="INFO" saaj="INFO" security="INFO" self-management="INFO" server="INFO" synchronization="INFO" util="INFO" verifier="INFO" web-container="INFO">
          <property name="com.sun.jbi" value="INFO"/>
          <property name="javax.enterprise.resource.webservices.jaxws" value="INFO"/>
          <property name="oracle.toplink.essentials" value="INFO"/>
        </module-log-levels>
      </log-service>
      <security-service activate-default-principal-to-role-mapping="false" anonymous-role="AttributeDeprecated" audit-enabled="false" audit-modules="default" default-realm="file" jacc="default">
        <!-- All administrative users use this realm by default. -->
        <auth-realm classname="com.sun.enterprise.security.auth.realm.file.FileRealm" name="admin-realm">
          <property name="file" value="${com.sun.aas.instanceRoot}/config/admin-keyfile"/>
          <property name="jaas-context" value="fileRealm"/>
        </auth-realm>
        <!-- All administrative users use this realm by default. -->
        <auth-realm classname="com.sun.enterprise.security.auth.realm.file.FileRealm" name="file">
          <property name="file" value="${com.sun.aas.instanceRoot}/config/keyfile"/>
          <property name="jaas-context" value="fileRealm"/>
        </auth-realm>
        <auth-realm classname="com.sun.enterprise.security.auth.realm.certificate.CertificateRealm" name="certificate">
    </auth-realm>
        <jacc-provider name="default" policy-configuration-factory-provider="com.sun.enterprise.security.provider.PolicyConfigurationFactoryImpl" policy-provider="com.sun.enterprise.security.provider.PolicyWrapper">
          <property name="repository" value="${com.sun.aas.instanceRoot}/generated/policy"/>
        </jacc-provider>
        <audit-module classname="com.sun.enterprise.security.Audit" name="default">
          <property name="auditOn" value="false"/>
        </audit-module>
        <message-security-config auth-layer="SOAP">
          <!-- turned off by default -->
          <provider-config class-name="com.sun.xml.wss.provider.ClientSecurityAuthModule" provider-id="XWS_ClientProvider" provider-type="client">
            <request-policy auth-source="content"/>
            <response-policy auth-source="content"/>
            <property name="encryption.key.alias" value="s1as"/>
            <property name="signature.key.alias" value="s1as"/>
            <property name="dynamic.username.password" value="false"/>
            <property name="debug" value="false"/>
          </provider-config>
          <provider-config class-name="com.sun.xml.wss.provider.ClientSecurityAuthModule" provider-id="ClientProvider" provider-type="client">
            <request-policy auth-source="content"/>
            <response-policy auth-source="content"/>
            <property name="encryption.key.alias" value="s1as"/>
            <property name="signature.key.alias" value="s1as"/>
            <property name="dynamic.username.password" value="false"/>
            <property name="debug" value="false"/>
            <property name="security.config" value="${com.sun.aas.instanceRoot}/config/wss-server-config-1.0.xml"/>
          </provider-config>
          <provider-config class-name="com.sun.xml.wss.provider.ServerSecurityAuthModule" provider-id="XWS_ServerProvider" provider-type="server">
            <request-policy auth-source="content"/>
            <response-policy auth-source="content"/>
            <property name="encryption.key.alias" value="s1as"/>
            <property name="signature.key.alias" value="s1as"/>
            <property name="debug" value="false"/>
          </provider-config>
          <provider-config class-name="com.sun.xml.wss.provider.ServerSecurityAuthModule" provider-id="ServerProvider" provider-type="server">
            <request-policy auth-source="content"/>
            <response-policy auth-source="content"/>
            <property name="encryption.key.alias" value="s1as"/>
            <property name="signature.key.alias" value="s1as"/>
            <property name="debug" value="false"/>
            <property name="security.config" value="${com.sun.aas.instanceRoot}/config/wss-server-config-1.0.xml"/>
          </provider-config>
        </message-security-config>
      </security-service>
      <transaction-service automatic-recovery="false" heuristic-decision="rollback" keypoint-interval="65536" retry-timeout-in-seconds="600" timeout-in-seconds="0" tx-log-dir="${com.sun.aas.instanceRoot}/logs"/>
      <monitoring-service>
        <module-monitoring-levels connector-connection-pool="OFF" connector-service="OFF" ejb-container="LOW" http-service="LOW" jdbc-connection-pool="OFF" jms-service="OFF" jvm="OFF" orb="OFF" thread-pool="OFF" transaction-service="OFF" web-container="LOW"/>
      </monitoring-service>
      <diagnostic-service capture-app-dd="true" capture-hadb-info="true" capture-install-log="true" capture-system-info="true" compute-checksum="true" max-log-entries="500" min-log-level="INFO" verify-config="true"/>
      <java-config classpath-suffix="" debug-enabled="false" debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009" env-classpath-ignored="true" java-home="${com.sun.aas.javaRoot}" javac-options="-g" rmic-options="-iiop -poa -alwaysgenerate -keepgenerated -g" system-classpath="">
        <!-- various required jvm-options -->
        <jvm-options>-XX:MaxPermSize=192m</jvm-options>
        <jvm-options>-client</jvm-options>
        <jvm-options>-Djava.endorsed.dirs=${com.sun.aas.installRoot}/lib/endorsed</jvm-options>
        <jvm-options>-Djava.security.policy=${com.sun.aas.instanceRoot}/config/server.policy</jvm-options>
        <jvm-options>-Djava.security.auth.login.config=${com.sun.aas.instanceRoot}/config/login.conf</jvm-options>
        <jvm-options>-Dsun.rmi.dgc.server.gcInterval=3600000</jvm-options>
        <jvm-options>-Dsun.rmi.dgc.client.gcInterval=3600000</jvm-options>
        <jvm-options>-Xmx512m</jvm-options>
        <jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks</jvm-options>
        <jvm-options>-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks</jvm-options>
        <jvm-options>-Djava.ext.dirs=${com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.javaRoot}/jre/lib/ext${path.separator}${com.sun.aas.instanceRoot}/lib/ext${path.separator}${com.sun.aas.derbyRoot}/lib</jvm-options>
        <jvm-options>-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver</jvm-options>
        <jvm-options>-Djavax.management.builder.initial=com.sun.enterprise.admin.server.core.jmx.AppServerMBeanServerBuilder</jvm-options>
        <jvm-options>-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory</jvm-options>
        <jvm-options>-Dcom.sun.enterprise.taglibs=appserv-jstl.jar,jsf-impl.jar</jvm-options>
        <jvm-options>-Dcom.sun.enterprise.taglisteners=jsf-impl.jar</jvm-options>
        <jvm-options>-XX:NewRatio=2</jvm-options>
        <!--
        Use the following jvm-options element to disable the quick startup:
        com.sun.enterprise.server.ss.ASQuickStartup=false
      -->
        <jvm-options>-XX:MaxPermSize=128m</jvm-options>
        <jvm-options>-XX:PermSize=128m</jvm-options>
        <jvm-options>-Dcom.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace=false</jvm-options>
      </java-config>
      <thread-pools>
        <thread-pool idle-thread-timeout-in-seconds="120" max-thread-pool-size="200" min-thread-pool-size="0" num-work-queues="1" thread-pool-id="thread-pool-1"/>
      </thread-pools>
      <management-rules enabled="true">
  </management-rules>
    </config>
    <!-- config model with name "server-config" ends -->
  </configs>
  <servers>
    <server config-ref="server-config" lb-weight="100" name="server">
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="adminapp" virtual-servers="__asadmin"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="admingui" virtual-servers="__asadmin"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="JBIFramework"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="WSTXServices"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="WSTCPConnectorLCModule"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="MEjbApp" virtual-servers="server"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="__ejb_container_timer_app" virtual-servers="server"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="__JWSappclients" virtual-servers="server"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="portletdriver" virtual-servers="server"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="cam"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="camBpelPlugin"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="aspects"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="CMS_PinChange_SA-CMS_PinChange_EJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="CMS_CardHolder_SA-CMS_CardHolder_EJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="MSG_SA-MSG_EJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="CMS_Custom_EJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="CMS_CATSA_EJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="LST_SA-LST_EJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="CMS_Card_SA-CMS_Card_EJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="CMS_Print_SA-CMS_Print_EJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="CMS_AuditTrail_SA-CMS_AuditLog_EJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="CMS_CATSA_SA-CMS_CATSA_EJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="ConfigurationManagerSA-ConfigurationManagerEJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="CMS_SA-CMS_EJB"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" lb-enabled="false" ref="CMS_TIMER_EA"/>
      <resource-ref enabled="true" ref="jdbc/__TimerPool"/>
      <resource-ref enabled="true" ref="jdbc/__CallFlowPool"/>
      <resource-ref enabled="true" ref="jdbc/__defaultDS"/>
      <resource-ref enabled="true" ref="jdbc/__default"/>
      <resource-ref enabled="true" ref="jdbc/__workflow"/>
      <resource-ref enabled="true" ref="jdbc/iepseDerbyNonXA"/>
      <resource-ref enabled="true" ref="jdbc/iepseDerbyXA"/>
      <resource-ref enabled="true" ref="jdbc/SQLExpress"/>
      <resource-ref enabled="true" ref="ConfigurationManagerEncryptionPassword"/>
      <resource-ref enabled="true" ref="ConfigurationManagerEncryptionSalt"/>
      <resource-ref enabled="true" ref="ConfigurationManagerFileLocation"/>
      <resource-ref enabled="true" ref="jms/CMSTopicFactory"/>
      <resource-ref enabled="true" ref="jms/cmsTopic"/>
      <resource-ref enabled="true" ref="jdbc/MasterDB"/>
      <resource-ref enabled="true" ref="jdbc/CMSAudit"/>
      <resource-ref enabled="true" ref="jdbc/CIDDB"/>
      <resource-ref enabled="true" ref="jdbc/RADDB"/>
      <resource-ref enabled="true" ref="jdbc/sample"/>
    </server>
  </servers>
  <property name="administrative.domain.name" value="domain1"/>
</domain>

Gavin Ross-2 wrote:

Please supply a copy of your domain.xml file. There may be a conflict in
your glassfish setup as I am running glassfish very well with upto 8
connection pools in a production environment without any issues.

Gavin Ross
Preferred Partner : The Bluebox
Cell: 0837038110
Email: [e-mail]


-----Original Message-----
From: jsexton0 [mailto:[e-mail]]
Sent: 04 May 2009 05:40 PM
To: [e-mail]
Subject: Re: [entpack] Derby Error Starting Glassfish



Hello -

I seem to have reached the inescapable conclusion that Derby can not handle
supporting the EJB timer service in Glassfish after the application reaches
a certain point.  And the only (drastic) choice is to reconfigure Glassfish
with a different database.

I only have one timer in my application, but a have been steadily adding SAs
and I have 3 or 4 DB connection pools, so I guess one of those pushes it
over the edge and prevents a valid start up?

It's hard to believe that something has not been overlooked here, it really
just doesn't work?  Simple as that?  Anyone else want to make a suggestion?

Thanks - here is the startup exception again, just in case.

JDO74009: Bean 'TimerBean' method ejbSelectAllTimersByOwnerAndState:
problems running JDOQL query with params [server, 0]
com.sun.jdo.api.persistence.support.JDODataStoreException: JDO76400: Got a
JDBC SQLException while executing the SQL statement: SQL statement<select
distinct t0."TIMERID", t0."CREATIONTIMERAW", t0."LASTEXPIRATIONRAW",
t0."CONTAINERID", t0."OWNERID", t0."STATE", t0."PKHASHCODE",
t0."INTERVALDURATION", t0."INITIALEXPIRATIONRAW" from "EJB__TIMER__TBL" t0
where t0."OWNERID" = CAST (? AS VARCHAR(32672)) and t0."STATE" = CAST (? AS
INTEGER)> with input values:java.lang.String:server, java.lang.Integer:0.
Please examine the SQLException for more information.
NestedException: java.sql.SQLTransactionRollbackException: A lock could not
be obtained within the time requested
        at
com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.throwJDOSqlExce
ption(SQLStoreManager.java:645)
        at
com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQ
LStoreManager.java:479)
        at
com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLSto
reManager.java:376)
        at
com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.ret
rieve(PersistenceManagerImpl.java:1118)
        at
com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(Query
Impl.java:689)
        at
com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArra
y(QueryImpl.java:607)
        at
com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersB
yOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
        at
com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServ
er(TimerBean.java:709)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecu
rityManager.java:1067)
        at
com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
        at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.ja
va:2895)
        at
com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvo
cationHandler.java:242)
        at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
        at
com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:49
1)
        at
com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactor
yImpl.java:364)
        at
com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.
java:348)
        at
com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:5
26)
        at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
        at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
NestedStackTrace:
java.sql.SQLTransactionRollbackException: A lock could not be obtained
within the time requested
        at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
Source)
        at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
Source)
        at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknow
n
Source)
        at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
Source)
        at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
        at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
        at
org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown
Source)
        at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown
Source)
        at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
        at
com.sun.jdo.spi.persistence.support.sqlstore.sql.ResultDesc.getResult(Result
Desc.java:490)
        at
com.sun.jdo.spi.persistence.support.sqlstore.sql.generator.SelectQueryPlan.g
etResult(SelectQueryPlan.java:1576)
        at
com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQ
LStoreManager.java:477)
        at
com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLSto
reManager.java:376)
        at
com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.ret
rieve(PersistenceManagerImpl.java:1118)
        at
com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(Query
Impl.java:689)
        at
com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArra
y(QueryImpl.java:607)
        at
com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersB
yOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
        at
com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServ
er(TimerBean.java:709)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecu
rityManager.java:1067)
        at
com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
        at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.ja
va:2895)
        at
com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvo
cationHandler.java:242)
        at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
        at
com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:49
1)
        at
com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactor
yImpl.java:364)
        at
com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.
java:348)
        at
com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:5
26)
        at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
        at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
Caused by: java.sql.SQLException: A lock could not be obtained within the
time requested
        at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source)
        at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossD
RDA(Unknown
Source)
        ... 38 more



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


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.287 / Virus Database: 270.12.15/2093 - Release Date: 05/02/09
14:23:00

[jsexton0]

I'm sorry, my fault.  I was leaving off the ';'
d'oh!

The queries work fine when I'm connected with ij.


Hello again...

I got connected using newer scripts in /javadb/bin rather than /frameworks/NewtworkServer/bin.
It's a little show to connect, and "show tables" seems to hang - with Glassfish not running.

jsexton0 wrote:

I get "no suitable driver" on the connect command.  What am I missing there?

This does in fact come up if I undeploy a few things, startup Glassfish, and re-deploy after it has finished it's start process.  But if, and only if, my full application is loaded when Glassfish start, then the EJB timer service fails to start due to the time-out selecting from Derby.  

Thanks

Manfred Riem wrote:

Hi there,

Have you tried executing the query against that database
yourself?

Manfred

> Hello -
>
> I seem to have reached the inescapable conclusion that Derby can not handle
> supporting the EJB timer service in Glassfish after the application reaches
> a certain point.  And the only (drastic) choice is to reconfigure Glassfish
> with a different database.
>
> I only have one timer in my application, but a have been steadily adding SAs
> and I have 3 or 4 DB connection pools, so I guess one of those pushes it
> over the edge and prevents a valid start up?
>
> It's hard to believe that something has not been overlooked here, it really
> just doesn't work?  Simple as that?  Anyone else want to make a suggestion?
>
> Thanks - here is the startup exception again, just in case.
>
> JDO74009: Bean 'TimerBean' method ejbSelectAllTimersByOwnerAndState:
> problems running JDOQL query with params [server, 0]
> com.sun.jdo.api.persistence.support.JDODataStoreException: JDO76400: Got a
> JDBC SQLException while executing the SQL statement:
> SQL statement<select distinct t0."TIMERID", t0."CREATIONTIMERAW",
> t0."LASTEXPIRATIONRAW", t0."CONTAINERID", t0."OWNERID", t0."STATE",
> t0."PKHASHCODE", t0."INTERVALDURATION", t0."INITIALEXPIRATIONRAW" from
> "EJB__TIMER__TBL" t0 where t0."OWNERID" = CAST (? AS VARCHAR(32672)) and
> t0."STATE" = CAST (? AS INTEGER)> with input values:java.lang.String:server,
> java.lang.Integer:0.
> Please examine the SQLException for more information.
> NestedException: java.sql.SQLTransactionRollbackException: A lock could not
> be obtained within the time requested
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.throwJDOSqlException(SQLStoreManager.java:645)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:479)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:376)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:1118)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:689)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArray(QueryImpl.java:607)
>         at
> com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersByOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
>         at
> com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServer(TimerBean.java:709)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
>         at
> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
>         at
> com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
>         at
> com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvocationHandler.java:242)
>         at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
>         at
> com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:491)
>         at
> com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactoryImpl.java:364)
>         at
> com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.java:348)
>         at
> com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:526)
>         at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
>         at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
> NestedStackTrace:
> java.sql.SQLTransactionRollbackException: A lock could not be obtained
> within the time requested
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
>         at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
>         at
> org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown
> Source)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.sql.ResultDesc.getResult(ResultDesc.java:490)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.sql.generator.SelectQueryPlan.getResult(SelectQueryPlan.java:1576)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:477)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:376)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:1118)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:689)
>         at
> com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArray(QueryImpl.java:607)
>         at
> com.sun.ejb.containers.TimerBean_2100919770_ConcreteImpl.ejbSelectAllTimersByOwnerAndState(TimerBean_2100919770_ConcreteImpl.java:1700)
>         at
> com.sun.ejb.containers.TimerBean.ejbHomeSelectAllActiveTimersOwnedByThisServer(TimerBean.java:709)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
>         at
> com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
>         at
> com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
>         at
> com.sun.ejb.containers.EJBLocalHomeInvocationHandler.invoke(EJBLocalHomeInvocationHandler.java:242)
>         at $Proxy24.selectAllActiveTimersOwnedByThisServer(Unknown Source)
>         at
> com.sun.ejb.containers.EJBTimerService.restoreTimers(EJBTimerService.java:491)
>         at
> com.sun.ejb.containers.ContainerFactoryImpl.restoreEJBTimers(ContainerFactoryImpl.java:364)
>         at
> com.sun.enterprise.server.ApplicationLifecycle.onReady(ApplicationLifecycle.java:348)
>         at
> com.sun.enterprise.server.ApplicationServer.onReady(ApplicationServer.java:526)
>         at com.sun.enterprise.server.PEMain.run(PEMain.java:413)
>         at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)
> Caused by: java.sql.SQLException: A lock could not be obtained within the
> time requested
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
> Source)
>         at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
> Source)
>         ... 38 more

[Manfred Riem]

Hi,

So that rules out a problem with the database. So it
must be in one of your applications. Would one of
your applications by accident try to use that resource?

Manfred

> I'm sorry, my fault.  I was leaving off the ';'
> d'oh!
>
> The queries work fine when I'm connected with ij.

[jsexton0]

I'm not sure...  I certainly have not coded anything that uses that database directly.  But here's something: I replaced the databases/ejbtimer directory entirely with the same directory from another (Windows) machine running the same edition of Glassfish/Netbeans.  Following this the server I'm working with has stopped and restarted flawlessly twice.

Manfred Riem wrote:

Hi,

So that rules out a problem with the database. So it
must be in one of your applications. Would one of
your applications by accident try to use that resource?

Manfred

[Manfred Riem]

Mmmmm,

Well if that fixed it ....

Manfred

> I'm not sure...  I certainly have not coded anything that uses that database
> directly.  But here's something: I replaced the databases/ejbtimer directory
> entirely with the same directory from another (Windows) machine running the
> same edition of Glassfish/Netbeans.  Following this the server I'm working
> with has stopped and restarted flawlessly twice.
>