[Design of JBoss jBPM] - Timer problem in jBPM
by hublisiddu
In our JBPM workflow, from submit request, there will be two node waiting for approval [irrsepctive of priority] once both gets approved then process will be complete. The wait time for approval is 10 minutes, if user doesn't approve in 10 minute, process needs to send email and wait for 10 more minutes, once it reaches total 30 minutes then node should automatically forward to end node. This process will same for both the the nodes.
The problem I am facing is, after submitting request when timer starts for both the nodes. in 10 minutes if no one approves the request then timer will check for 30 mins check[whether it finishes 30 mins], sends mail accordingly and either remain in same node or go to end state depending on time check.The samething happens in other node as well. But both try to access the same thread of job executor and creating delegation exception. If I keep different time check for both then it works but if both try to access thread at same time then I am getting delegation exception.
If anyone knows possible solution for this problem then their help and guidance is very much appreciated.
Thanks in advance,
Siddu
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4231176#4231176
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4231176
15 years
[Design of JBoss jBPM] - values in example.identities.sql for JBPM4_ID_USER do not fi
by mrinneL1
This issue applies to revision 4815 and some earlier revisions.
The script example.identities.sql contains lines like
INSERT INTO JBPM4_ID_USER VALUES (1,0,'alex','password','Administrator Login','');
but the script jbpm.hsqldb.create.sql creates the JBPM4_ID_USER table as follows
create table JBPM4_ID_USER (
| DBID_ bigint generated by default as identity (start with 1),
| DBVERSION_ integer not null,
| ID_ varchar(255),
| PASSWORD_ varchar(255),
| GIVENNAME_ varchar(255),
| FAMILYNAME_ varchar(255),
| BUSINESSEMAIL_ varchar(255),
| primary key (DBID_)
| );
The value 'Administrator Login' does not fit to the columns GIVENNAME_ and FAMILYNAME_.
The script example.identities.sql should be changed to use something like
INSERT INTO JBPM4_ID_USER VALUES (1,0,'alex','password','Alex','Admin','');
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4231138#4231138
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4231138
15 years
Re: jBPM 4 limitations
by Tom Baeyens
>>> Do we limit the support of jBPM to just JBoss EAP & SOA-P?
>>> Historically, we've supported BEA, IBM, Tomcat, J2SE, etc.
>>
>> Yes. Unless we have QA set of for it in the project.
> I have always felt this was an unnecessary risk and had asked for this
> limitation before now and it will be a problem for several jBPM 3
> users/customers.
you mean that they're using it on e.g. tomcat, which won't be supported in the future ?
we'll have to prioritize what we want to support. for each target, we can build out
the qa. but it has to be prioritized and the qa infrastructure has to be in place
before we sell support on it.
we realized that jbpm 3 was basically not supportable when it was being added to the
platform. but we didn't have a choice. in retrospective, it would have been good to
limit the deployment and dbs instead of just supporting every client's need/wish.
> However, we can increase our "platform" support in
> future months based on specific user feedback.
exactly. prioritize, build qa infrastructure and then its done. it's for this type
of tasks that productization people could give us a hand. this work is not very
involved into the codebase. it just requires a bit of discussion on how we're going
to deploy on tomcat and how the test suite needs to be configured.
currently all this work boils down to the core developers and i hope that we'll be
able to find some hands that can help us with that. especially since this is work
that previously was done as part of the productization cycle. and now we're
incorporating that into the project as we now know that we'll be the ones that have
to use that qa infrastructure to handle the difficult support cases.
> WAS, WLS, EWS (supported Tomcat) would be higher priorities in my book
> but I understand the project's need to be seen as Tomcat friendly in
> order to increase adoption.
it's also a matter of what we know: for tomcat i could get started myself and get it
done fairly quickly. for WAS and WLS i wouldn't know where to start in terms of
licenses, automatic installation and things like that. again, i believe that is an
area where productization people can help.
> OK, I'm assuming that you'll work closely with Kevin whenever the
> integration task comes up in the future.
Our current integration is based on what Kevin did. Heiko build it and did a good
job. We already had Kevin review and it was indeed like he expected/wanted.
>> It is targetted to ship with SOA-P 5. They seem to be on track as well.
> But what about EAP/AS users? We'll need to support that as a platform
> with the identity component.
The project/product hierarchy that has been set up in this company has not been
helping in this respect. We were focussed on SOA-P. We knew that SEAM includes jBPM
but the current organisation structure doesn't establish that. The current
organisation on jBPM/SEAM/EAP/SOA-P seems a bit broken to me. I can understand the
commercial reasons and positioning, but we need to fix the practical organisation
part. We're currently doing that ad hoc after the facts.
>>>>> * no async messaging through JMS
>>> That will make some jBPM3 users unhappy. NTT feels this will add
>>> scalability, especially in a cluster.
>>
>> Same here. We have all functional components in place, but except for
>> QA. Setting that up requires productization resources which we don't
>> have. So that work is now serialized and will have to be prioritized
>> after GA.
> This one feels a bit "high priority" to me only because some high
> profile customer made such a big deal out of it. With that said, I'm
> not sure if the jBPM4 architecture without JMS is vastly better than
> jBPM3 therefore the need for JMS just goes away. Only you can make that
> call.
first thing we need is qa infrastructure so that we can debug every customer problem
with the job executor. then we can zoom in and fix every issue if it pops up. then
the only other downside could be performance, which is never critical. and
performance of the job executor won't be bad either.
i'm confident that with the new job executor and the QA we have in place for it, the
current problems will go away. if that turns out to be a false assumption, then we
can still add JMS support fairly quickly. we have all the components in place. only
the configurability and QA needs to be set up for it.
>> But in terms of disabling actual features as part of the sanetization
>> process, i didn't give that much thought yet.
> OK, either we need to be able to "cut" the feature out of the product
> zip OR we need to make it really easy in the docs to see that it is
> "technology preview". Ideally it would just get removed. We did this
> recently with Drools->BRMS, several files from the .org version were
> removed as they were too experimental.
from the engine point of view, we have a clear separation. but i start to realize
that some sanetizations might have a big impact on the designer and console tooling.
so for each sanetization we have to consider that impact.
but that is not a problem for now. we focus on building out the product features
first. so there is no sanetization needed for jbpm 4 at this stage.
regards, tom.
Burr Sutter wrote:
>
>
> Tom Baeyens wrote:
>>
>>
>> Burr Sutter wrote:
>>>
>>>
>>> Tom Baeyens wrote:
>>>> 2 more
>>>>
>>>> * no user provided hibernate sessions
>>>> * no user provided jdbc connections
>>>>
>>> Would our jBPM3 customers think these are "losses"?
>>
>> in my estimation, I think that less then 1% of our users uses this
>> feature.
> Very good, I think you, Alejandro and Martin would have the best insight
> into what features are used or not.
>>
>>>> regards, tom.
>>>>
>>>>
>>>> Tom Baeyens wrote:
>>>>> Burr,
>>>>>
>>>>> In jBPM 4 one of the main goals is to improve the supportability.
>>>>> Therefor we are seriously expanding the QA capabilities in the
>>>>> project.
>>>>>
>>>>> Another part of that is clearly indicate what environments and
>>>>> configurations we support and which not.
>>>>>
>>>>> Here are a couple of limitations that I'ld like to start with from
>>>>> a product perspective:
>>>>>
>>>>> * only one jBPM instance on a jboss server
>>> Can I have several .wars or .ears that all use that jBPM instance?
>>
>> yes
>>
> Excellent, I think that is pretty critical, at least for smaller shops &
> developers. Large IT shops may only have a single application running
> on a single instance of AS but I don't think that is the norm.
>>>>> * only installation and configuration of jbpm as in the soa platform
>>> What does this statement mean?
>>
>> configuration of transaction related stuff:
>> - jbpm configured to bind to JTA
>> - jbpm command interceptor with JTA required semantics
>> - jbpm configured to use hibernate's current session
>> - jbpm configured to not create hibernate transactions
>> - hibernate configured with a xa datasource
>> - job executor configured as in the soa platform
>>
>> we create a set of configurations for jBPM, app server and hibernate
>> so that it works. users have to stick with the configuration we
>> provide and for which we have QA set up.
>>
>> we saw in jbpm 3 that a lot of users burned their fingers if they
>> start messing with these transactional settings. e.g. let spring
>> manage the transaction.
>>
>> jbpm 4 has improved conofigurability. but we must only support those
>> configuration sets for which we have QA running.
> Solid strategy.
>>
>>>>> - distribution ships with an ant based installer that installs
>>>>> jbpm into jboss
>>> Do we limit the support of jBPM to just JBoss EAP & SOA-P?
>>> Historically, we've supported BEA, IBM, Tomcat, J2SE, etc.
>>
>> Yes. Unless we have QA set of for it in the project.
> I have always felt this was an unnecessary risk and had asked for this
> limitation before now and it will be a problem for several jBPM 3
> users/customers. However, we can increase our "platform" support in
> future months based on specific user feedback.
>>
>> With the infrastructure we have in place now, it should be pretty
>> straightforward to add such a container like e.g. Tomcat. But it
>> takes work that has lower priority then embedding jBPM 4 into SOA-P 5.
>>
>> This is just a resource issue. In the project, next target (after
>> SOA-P 5) would be Tomcat. I don't know know when we'll be able to
>> deliver on that as SOA-P 5 takes precedence.
> WAS, WLS, EWS (supported Tomcat) would be higher priorities in my book
> but I understand the project's need to be seen as Tomcat friendly in
> order to increase adoption.
>>
>>>>> - jbpm is installed in jbpm as a service archive
>>> jBPM is already be pre-installed inside of SOA-P, is there anything
>>> in jBPM4 that requires it to be in a .sar?
>>
>> jBPM 4 installation is a combination of a sar, libs, configs and some
>> ejbs.
>>
>> the sar part is necessary to publish the central jbpm ProcessEngine
>> object into JNDI when JBoss boots.
> OK, I'm assuming that you'll work closely with Kevin whenever the
> integration task comes up in the future.
>>
>>>>> - jbpm ProcessEngine is published in JNDI
>>> Sounds good
>>>>> - hibernate session factory configuration as part of the jbpm
>>>>> installation
>>> Does this mean that a user can't "hijack" the hibernate session and
>>> "work around" jBPM's use?
>>
>> They can but we should not support those scenarios until we have QA
>> set up for these.
> Makes sense to me.
>>
>>>>> - jta transaction integration
>>> excellent
>>>>> - timer and async message run through our JobExecutor
>>>>> * only jboss idm identity component integration
>>> Will the JBoss Identity component ship with EAP5? Or is this a
>>> component that jBPM will include in its own jars?
>>
>> It is targetted to ship with SOA-P 5. They seem to be on track as well.
> But what about EAP/AS users? We'll need to support that as a platform
> with the identity component.
>>
>>>>> * no async messaging through JMS
>>> That will make some jBPM3 users unhappy. NTT feels this will add
>>> scalability, especially in a cluster.
>>
>> Same here. We have all functional components in place, but except for
>> QA. Setting that up requires productization resources which we don't
>> have. So that work is now serialized and will have to be prioritized
>> after GA.
> This one feels a bit "high priority" to me only because some high
> profile customer made such a big deal out of it. With that said, I'm
> not sure if the jBPM4 architecture without JMS is vastly better than
> jBPM3 therefore the need for JMS just goes away. Only you can make that
> call.
>>
>>>>> * no timer support through EJB Timer
>>>>> * no spring transaction integration.
>>>>>
>>>>> We might be offering those to the community in order to get
>>>>> feedback and flesh these out. But until those extra features get
>>>>> stable and we have the necessary QA build out, I would like not to
>>>>> introduce those into the product. This focus will help us to
>>>>> deliver in time.
>>>>>
>>>>> Do these seem reasonable limitations to you ?
>>> Will these items ship in the .jars/.zips that we send to customers?
>>
>> Good question. We're building the userguide docs so that those can be
>> shipped as-is to customers.
>>
>> But in terms of disabling actual features as part of the sanetization
>> process, i didn't give that much thought yet.
> OK, either we need to be able to "cut" the feature out of the product
> zip OR we need to make it really easy in the docs to see that it is
> "technology preview". Ideally it would just get removed. We did this
> recently with Drools->BRMS, several files from the .org version were
> removed as they were too experimental.
>>
>>>>> Do you see other jBPM aspects that need clarification if they are
>>>>> supported or not ?
>>> Martin P would be one of the best resources to ask what should be
>>> "in" vs "out".
>>
> I've copied Martin, I guess I should have from the "get go".
>
--
regards, tom.
15 years
Re: jBPM 4 limitations
by Tom Baeyens
>>>>> * only one jBPM instance on a jboss server
>>> Can I have several .wars or .ears that all use that jBPM instance?
>>
>> yes
>>
> Excellent, I think that is pretty critical, at least for smaller shops &
> developers. Large IT shops may only have a single application running
> on a single instance of AS but I don't think that is the norm.
the only diff is publishing the ProcessEngine over JNDI.
without the service archive integration, community users can still put the jbpm into
their jboss lib directory, in which case all applications would see it. jbpm has a
cache so that the second time you fetch the configuration for a certain resource file
you'll get the same one as the first time. this is not so managed as in jndi, but
gets the same thing.
and usually users (the smaller shops) don't have a big problem with just including
the jars in their app.
so all is possible. but the sar deployment will be the supported deployment. and
that is just the same as the soa guys have done it with jbpm 3 in the soa platform.
the only difference is that this time, we have build it, we maintain it and we can
have our QA running on it and we can dive in there and fix things if necessary.
previously we had to fix blind when problems were reported at this level. these
things should have been contributed to the project in the first place. that's what
we've made sure in jbpm4.
that that's what i'll try to encourage as much as possible in the productization
process. all aspects for which we need to fix bugs in the project, we have to have
the infrastructure in the project to do it.
regards, tom.
Burr Sutter wrote:
>
>
> Tom Baeyens wrote:
>>
>>
>> Burr Sutter wrote:
>>>
>>>
>>> Tom Baeyens wrote:
>>>> 2 more
>>>>
>>>> * no user provided hibernate sessions
>>>> * no user provided jdbc connections
>>>>
>>> Would our jBPM3 customers think these are "losses"?
>>
>> in my estimation, I think that less then 1% of our users uses this
>> feature.
> Very good, I think you, Alejandro and Martin would have the best insight
> into what features are used or not.
>>
>>>> regards, tom.
>>>>
>>>>
>>>> Tom Baeyens wrote:
>>>>> Burr,
>>>>>
>>>>> In jBPM 4 one of the main goals is to improve the supportability.
>>>>> Therefor we are seriously expanding the QA capabilities in the
>>>>> project.
>>>>>
>>>>> Another part of that is clearly indicate what environments and
>>>>> configurations we support and which not.
>>>>>
>>>>> Here are a couple of limitations that I'ld like to start with from
>>>>> a product perspective:
>>>>>
>>>>> * only one jBPM instance on a jboss server
>>> Can I have several .wars or .ears that all use that jBPM instance?
>>
>> yes
>>
> Excellent, I think that is pretty critical, at least for smaller shops &
> developers. Large IT shops may only have a single application running
> on a single instance of AS but I don't think that is the norm.
>>>>> * only installation and configuration of jbpm as in the soa platform
>>> What does this statement mean?
>>
>> configuration of transaction related stuff:
>> - jbpm configured to bind to JTA
>> - jbpm command interceptor with JTA required semantics
>> - jbpm configured to use hibernate's current session
>> - jbpm configured to not create hibernate transactions
>> - hibernate configured with a xa datasource
>> - job executor configured as in the soa platform
>>
>> we create a set of configurations for jBPM, app server and hibernate
>> so that it works. users have to stick with the configuration we
>> provide and for which we have QA set up.
>>
>> we saw in jbpm 3 that a lot of users burned their fingers if they
>> start messing with these transactional settings. e.g. let spring
>> manage the transaction.
>>
>> jbpm 4 has improved conofigurability. but we must only support those
>> configuration sets for which we have QA running.
> Solid strategy.
>>
>>>>> - distribution ships with an ant based installer that installs
>>>>> jbpm into jboss
>>> Do we limit the support of jBPM to just JBoss EAP & SOA-P?
>>> Historically, we've supported BEA, IBM, Tomcat, J2SE, etc.
>>
>> Yes. Unless we have QA set of for it in the project.
> I have always felt this was an unnecessary risk and had asked for this
> limitation before now and it will be a problem for several jBPM 3
> users/customers. However, we can increase our "platform" support in
> future months based on specific user feedback.
>>
>> With the infrastructure we have in place now, it should be pretty
>> straightforward to add such a container like e.g. Tomcat. But it
>> takes work that has lower priority then embedding jBPM 4 into SOA-P 5.
>>
>> This is just a resource issue. In the project, next target (after
>> SOA-P 5) would be Tomcat. I don't know know when we'll be able to
>> deliver on that as SOA-P 5 takes precedence.
> WAS, WLS, EWS (supported Tomcat) would be higher priorities in my book
> but I understand the project's need to be seen as Tomcat friendly in
> order to increase adoption.
>>
>>>>> - jbpm is installed in jbpm as a service archive
>>> jBPM is already be pre-installed inside of SOA-P, is there anything
>>> in jBPM4 that requires it to be in a .sar?
>>
>> jBPM 4 installation is a combination of a sar, libs, configs and some
>> ejbs.
>>
>> the sar part is necessary to publish the central jbpm ProcessEngine
>> object into JNDI when JBoss boots.
> OK, I'm assuming that you'll work closely with Kevin whenever the
> integration task comes up in the future.
>>
>>>>> - jbpm ProcessEngine is published in JNDI
>>> Sounds good
>>>>> - hibernate session factory configuration as part of the jbpm
>>>>> installation
>>> Does this mean that a user can't "hijack" the hibernate session and
>>> "work around" jBPM's use?
>>
>> They can but we should not support those scenarios until we have QA
>> set up for these.
> Makes sense to me.
>>
>>>>> - jta transaction integration
>>> excellent
>>>>> - timer and async message run through our JobExecutor
>>>>> * only jboss idm identity component integration
>>> Will the JBoss Identity component ship with EAP5? Or is this a
>>> component that jBPM will include in its own jars?
>>
>> It is targetted to ship with SOA-P 5. They seem to be on track as well.
> But what about EAP/AS users? We'll need to support that as a platform
> with the identity component.
>>
>>>>> * no async messaging through JMS
>>> That will make some jBPM3 users unhappy. NTT feels this will add
>>> scalability, especially in a cluster.
>>
>> Same here. We have all functional components in place, but except for
>> QA. Setting that up requires productization resources which we don't
>> have. So that work is now serialized and will have to be prioritized
>> after GA.
> This one feels a bit "high priority" to me only because some high
> profile customer made such a big deal out of it. With that said, I'm
> not sure if the jBPM4 architecture without JMS is vastly better than
> jBPM3 therefore the need for JMS just goes away. Only you can make that
> call.
>>
>>>>> * no timer support through EJB Timer
>>>>> * no spring transaction integration.
>>>>>
>>>>> We might be offering those to the community in order to get
>>>>> feedback and flesh these out. But until those extra features get
>>>>> stable and we have the necessary QA build out, I would like not to
>>>>> introduce those into the product. This focus will help us to
>>>>> deliver in time.
>>>>>
>>>>> Do these seem reasonable limitations to you ?
>>> Will these items ship in the .jars/.zips that we send to customers?
>>
>> Good question. We're building the userguide docs so that those can be
>> shipped as-is to customers.
>>
>> But in terms of disabling actual features as part of the sanetization
>> process, i didn't give that much thought yet.
> OK, either we need to be able to "cut" the feature out of the product
> zip OR we need to make it really easy in the docs to see that it is
> "technology preview". Ideally it would just get removed. We did this
> recently with Drools->BRMS, several files from the .org version were
> removed as they were too experimental.
>>
>>>>> Do you see other jBPM aspects that need clarification if they are
>>>>> supported or not ?
>>> Martin P would be one of the best resources to ask what should be
>>> "in" vs "out".
>>
> I've copied Martin, I guess I should have from the "get go".
>
--
regards, tom.
15 years
Re: AW: [jbpm-dev] Re: jBPM 4 limitations
by Tom Baeyens
Burr Sutter wrote:
> Hey Bernd,
>
> We have one user who believes the JMS-based JobExecutor is the only
> stable one on jBPM3.
we never have been able to reproduce that.
> Is the jBPM4 JobExecutor vastly better in architecture/design to make it
> superior to the JMS-based solution?
only problem with JMS is building out the QA. and building out the knowledge of the
specific JMS configuration options that might impact the execution of jobs
(redelivery, retries and so on)
that is why in jbpm 4 we opted to prioritize the job executor first. after that we
can prioritize JMS binding of asynchronous messaging.
apart from that, the jBPM 4 JobExecutor has been optimized significantly. all job
executor threads within one jBPM instance will not be competing any more for
acquiring jobs.
and our first focus is to build out QA infrastructure so that we can reproduce and
analyse *any* customer problem.
discuss if you don't think these are not the right priorities.
regards, tom.
> Burr
>
> Bernd Rücker wrote:
>> Hi!
>>
>> A short comment on JMS and EJB Timers: Currently you can either use both
>> or none. And since EJB Timers fail to scale well, in the bigger projects I
>> know we always used the JobExecutor and skipped JMS and EJB Timers. And
>> the JobExecutor scales perfectly well, so this is not a problem in my
>> eyes. Maybe to not have the JMS Marketing sticker is not that good, but
>> this is for you to judge...
>>
>> Cheers
>> Bernd
>>
>> -----Ursprüngliche Nachricht-----
>> Von: jbpm-dev-bounces(a)lists.jboss.org
>> [mailto:jbpm-dev-bounces@lists.jboss.org] Im Auftrag von Tom Baeyens
>> Gesendet: Montag, 11. Mai 2009 11:04
>> An: Burr Sutter
>> Cc: Len DiMaggio; jBPM Dev List; Mark Little; John Graham
>> Betreff: [jbpm-dev] Re: jBPM 4 limitations
>>
>>
>>>>>> * no async messaging through JMS
>>>>>>
>>>> That will make some jBPM3 users unhappy. NTT feels this will add
>>>> scalability, especially in a cluster.
>>>>
>>> Same here. We have all functional components in place, but except for
>>>
>> QA. Setting that up requires productization resources which we don't
>> have. So that work is now serialized and will have to be > > prioritized
>> after GA.
>>
>>
>>>>> * no timer support through EJB Timer
>>>>>
>>
>>
>>
>>
--
regards, tom.
15 years
AW: AW: [jbpm-dev] Re: jBPM 4 limitations
by Bernd Rücker
Hi Burr,
would be interesting why he thinks so, since I believe the
Non-JMS-JobExecutor is stable as well (and we did some stress testing in
one project). Only advantage of JMS is to maybe have existing JMS tooling
available (to monitor the DLQ and so on) in my opinion.
Cheers
Bernd
Von: Burr Sutter [mailto:bsutter@redhat.com]
Gesendet: Donnerstag, 14. Mai 2009 01:44
An: Bernd Rücker
Cc: 'Tom Baeyens'; 'Len DiMaggio'; 'jBPM Dev List'; 'Mark Little'; 'John
Graham'
Betreff: Re: AW: [jbpm-dev] Re: jBPM 4 limitations
Hey Bernd,
We have one user who believes the JMS-based JobExecutor is the only stable
one on jBPM3.
Is the jBPM4 JobExecutor vastly better in architecture/design to make it
superior to the JMS-based solution?
Burr
Bernd Rücker wrote:
Hi!
A short comment on JMS and EJB Timers: Currently you can either use both
or none. And since EJB Timers fail to scale well, in the bigger projects I
know we always used the JobExecutor and skipped JMS and EJB Timers. And
the JobExecutor scales perfectly well, so this is not a problem in my
eyes. Maybe to not have the JMS Marketing sticker is not that good, but
this is for you to judge...
Cheers
Bernd
-----Ursprüngliche Nachricht-----
Von: jbpm-dev-bounces(a)lists.jboss.org
[mailto:jbpm-dev-bounces@lists.jboss.org] Im Auftrag von Tom Baeyens
Gesendet: Montag, 11. Mai 2009 11:04
An: Burr Sutter
Cc: Len DiMaggio; jBPM Dev List; Mark Little; John Graham
Betreff: [jbpm-dev] Re: jBPM 4 limitations
* no async messaging through JMS
That will make some jBPM3 users unhappy. NTT feels this will add
scalability, especially in a cluster.
Same here. We have all functional components in place, but except for
QA. Setting that up requires productization resources which we don't
have. So that work is now serialized and will have to be > > prioritized
after GA.
* no timer support through EJB Timer
15 years
