J2SE Timer, lets deprecate it.

On the whole, the J2SE Timer looks like a good idea. Who wouldn't want to have a lightweight timer service. But, it's a problem for J2EE or managed server vendors because it wasn't designed correctly.

The problem with it is that it's an implementation rather than a set of interfaces. The J2SE Timer makes its own threads, and assumes that the TimerListener can be just called on that private thread.

When I did the WAS-E AlarmManager, I realized that the listener needed to be called with the same J2EE context as the creator of the alarm. So, if user B running on component C registered the alarm to expire in 50ms, then when the alarm expires, the listener also needs to be invoked as user B with the J2EE environment for component C setup.

I could have used an EJB for the listener but then what about servlet users, why force them to use an EJB? So, servlet customers can use JavaBeans as their listeners and when they are invoked on these asynchronous events, then they have access to the JNDI from the owning webapp, the security credential (if present). The JNDI is important because when an application looks up databases, ejbs or web services then it does this through JNDI. If the JNDI for the creating component was not available then the absolute JNDI name would have to be hard coded (or property) in the application, this defeats the reasoning behind the whole ref thing.

The J2EE 1.4 Timer Beans are similarly flawed as it's too EJB specific. If we'd have an interface based J2SE timer API then arguably it could have used it also. So, timer beans will require servlet customers to now use EJBs to gain access to those services. Now, timer service is a transactional scheduler but the point is it's APIs are very simple and arguably the session bean could have just extended the TimerListener interface or something. Also, the EJB gains access to the TimerService through EJBContext and I'd prefer to have the EJB use the resource-ref mechanism like I did with WorkManagers and the spec does with DataSources/ConnectionFactories. But, it's here, it ain't changing easily.

So, if WebSphere wanted to provide a lightweight timer service to J2EE applications that the J2SE timer APIs are just not suitable because they are an implementation which assumes an unmanaged environment and worse, they are an implementation and not an API so we couldn't even reuse the interfaces and hence, this is why I implemented the AlarmManager interfaces in WAS-E.

Comments

[Nicholas]

Do you mean J2SE timer ? Or J2EE timer ? The J2SE time is java.util.Timer. Not spectacular, but pretty harmless... should not be an issue in J2EE.

[Billy]

It's an issue. It's an implementation and doesn't let me provide the function. It makes it's own threads, it calls the expired timers on its own thread and doesn't give me a way to make the thread a managed one with the right J2EE context. It's a naked thread and hence busts in a managed environment.

[Greg]

One of the many negatives of EJBs. There are so many occasions where the inherent limitations of EJBs recently have made me question using them, even stateless session beans. You can't create threads, you can't (necessarily) open files, testing is complicated by the fact that it has to be "in container", entity beans are inefficient enough that you have to torque your object design if you choose to use them, etc.

About the only advantage (possibly) IMHO is the transactional features, but once you decide to create a "service" interface layer, it isn't like it is THAT hard to do the new UserTransaction, commit/rollback code.

Servlets with packages like hibernate and good separation of layers provide most of the benefit without all of the negatives.

[Billy]

Servlets are great except for that fact that the business logic gets trapped. You can expose it using XML-RPC or something like that but arguable EJBs offer a 'better' design and as always with 'better', it depends on the customer and application.

There are advantages to being in a container, servlets run in a container. The main inconvenience of EJBs versus servlets is rmic and there is a stub generator in most RPC mechanisms otherwise the application is doing marshalling.

As you can see from WAS, we're working hard to remove can't from the J2EE vocabulary.
As for CMP versus Hibernate, I don't think there is anything inherently faster in either approach, it's a question of the maturity of the underlying persistence manager. The benchmarks (jSpec, ECPerf) are quickly driving major performance gains in the CMP PMs from the vendors. I'd be surprised if they were significantly slower than any other PM implementation at this point.

CMPs are only slightly disadvantaged when compared with a Java Bean based PM like Hibernate. I don't think it's as big an issue as you indicate.

I'd like to see benchmarks modified to use various JDO implementations and some comparisons made between Oracle/BEA/WebSphere and Hibernate. I'd just be keen to make sure the sames rules apply to both, i.e. no silly caching, jSpecApp has rules about this.

[Jeff Morton]

IS the AlarmManager available in EE only? If so, are there any other alternatives to AlarmManager?

[Billy]

Yep, it's WAS-E only an they aren't any other alternatives.

[John]

I believe that you have used the wrong tool. J2SE = Java 2 Standard Edition. It is NOT designed to be used in a distributed or managed environment. So, I think you should not bash it that much. J2SE was designed for you to write two things:
1) Applications
2) Applets

Not Distributed, multi-users, Enterprise Level software.

That's why there is a timer in J2EE. Now, you've got the J2EE 1.4 timer, you are arguing about it cannot be used in J2SE. I mean, don't you use the right tool to do the right?

For example, you can certainly use a fork to drink soup, but is it proper?

Also, you can use a spoon to cut steak, but is it easy to do so?

You can use a knife to eat rice, you'll just cut yourself.

Everything has it own purpose. So, I disagree your claim.

I understand why you want to do this, you are trying to promote the new BEA/IBM spec for the new Timer Spec. That's what I think. I know you like your product, your work, but that does not mean the others' effort and products are useless, flawed. Please be considerate to others' work.

Hope you understand, this is not a flame, okay.

Thanks,
John

[Billy]

John,
You're advocating having N programming models for the same thing. Why do we need N models? 1 for J2SE Timers, another for persistent EJB based timers etc. It increases tooling costs, forces programmers to learn N ways to do the same thing etc. It's a flawed argument.

Billy

[Francis]

If I just want to use servlet to create a polling process, if J2SE Timer class can be used? As it create it own thread, any protential problem?

If I don't use Timer class, I can start a thread from servlet, thread will sleep fixed period time, then wake up....

Any difference with two approach ?

Thanks.

[Billy]

No,
The servlet spec would have you believe that they can use threads and Timers. But, the J2EE spec clarifies it and says that neither is porta ble. The problem is that when the Timer expires or the thread starts, the J2EE server can't put the correct environment on the thread. This means that when you call in to WAS that you'll likely see null pointer exceptions etc as WAS is written to expect this environment in TLS, for example.

[Akash]

Hi ,
I would like to use a time based event in my application which would ping a paricular server and persist the availability in a DB.
Which one would best suit me (Iam using a WAS 5.1 server.)
Does WSAD 5.1 provide a timer bean facility...? I doubt.