Hi marina,
On Wed, Sep 8, 2010 at 12:44 AM, <glassfish_at_javadesktop.org> wrote:
> First of all, you do not have POJOs, you have EJB Singletons :).
>
OK - I often read things like the following:
*Singleton beans, which are like any other EJB, are POJOs that are marked as
Singleton beans with the**_at_Singleton** annotation. Optionally, the bean can
be marked as a Singleton using a deployment descriptor. In effect, Singleton
beans are like stateless session beans except that they are not pooled and
there can be only one Singleton bean instance per JVM.*
In any event, yes these are obviously Singleton Beans.
> Now back to the original problem: persistent EJB Timer is created for each
> corresponding @Schedule annotation on deploy. On server restart they are
> only restarted. This is per EJB 3.1 spec requirements. If a timer failed
> delivery (twice by default) for some reason, it will be cancelled and never
> restarted again. You need to redeploy your application to recreate EJB
> Timers.
>
Would there not be some sort of exception thrown by the container to the
server.log if a timer fails delivery? If so, what might that look like?
> But if you have a reproducible test case, where @DependsOn affects EJB
> Timer creation, please file a bug in the ejb-container subcategory.
>
I don't know if it is the @DependsOn which is the cause. All I know is I
have some code that does have @DependsOn which will *sometimes* (even go so
far as to say rarely) fail to fire on server restart.
Could it a timing issue that since one of these if firing once per second
that I might run into a situation where it is trying to fire as I am
shutting down (or restarting) GF and the shutdown/restart triggers a timer
delivery failure that is recorded? How does GF persist the failure count
between server restarts? Can I view this information?
Thanks,
-Noah
> Regards,
> -marina
> [Message sent by forum member 'mvatkina']
>
> http://forums.java.net/jive/thread.jspa?messageID=482067
>
>