Kris Philippaerts

+ Follow
since Oct 19, 2001
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Kris Philippaerts


I set up my web application with these login settings:


When my session times out, the user is asked to log in again. But this often happens when the session contains information to build up the JSP. So, when I log in again, I get JSP exceptions (NoBeanSpecified, etc.), since this session information is lost. So it would be more suitable to show a message like: 'please close all pop-up windows and login again'. But I can't seem to configure this in my web.xml.

Is there a simple solution for this problem?

Thanks a lot!

12 years ago
Great! Thanks a lot. I'll have to think which option to choose, since the application runs at two sites. So I might want to leave the configuration as much applicationserver-sided as possible. But at least I can do some testing now.

Really appreciate your help!

Probarbly an easy question:

we have a query that performs some joins on big tables. When we execute it on our Informix database, it takes quite a while to execute. We had the query analyzed by our Informix specialists, but they say there are no big optimizations left.

When we use the query in our J2EE application (on Bea Weblogic 8.1), the application fails with a TimeOutException, and rolls back the transaction. The same application deployed at an other site with a smaller database does everything perfect.

The header of the exception is:

So my question is: how can I increase the timeout of.. I don't know, my beans? My connection? My...? Is this ejb-jar.xml configuration? Or application server configuration?

Any pointers are welcome!

Thanks a lot for your time!



I just found out that bea weblogic default timout is 300 seconds. How come I get a timeout after 29 seconds? Can this also be a database setting?
[ April 21, 2005: Message edited by: Kris Philippaerts ]
Testing serves more than one purpose. First, unit tests can more or less express the requirements of your projects. In theory, you should be able to write a bunch of tests, covering the entire scope of the project. After implementing the code that makes all the tests pass, your project should be finished. In this perspective, test-first programming makes you write only the necessary code, so you won't write one line of code too much, and you wont write an untested line of code. In real life, you should try to get as close to this theory as possible... So, this first point is more like a methodology, and not so much a time saving solution.

Second, writing tests for you classes really avoids a lot of bugs. And you will probarbly know, the later you find a bug, the more it will cost to fix it.

Third, and if you ask me, the most interesting point of all, testing your code gives you a huge advantage during refactoring or rewriting your code. Changing one little piece of code can make an onther (totaly different) piece of code not work properly anymore. And this happens a lot! Your tests will instantly point out the places where problems might occur. And this is definately a time saver!

So, writing tests will not be something that you have to sell to your customer. It will give you a methodology to write flexible quality code (i.e. more flexible and less bugs than untested code). It will help you to translate your use cases/user stories in code and will save a lot of time when exisiting code is refactored, rewritten or even extended.

[ September 05, 2004: Message edited by: Kris Philippaerts ]
13 years ago

Originally posted by David Harkness:
I would say first to make sure you're storing the results of reflection for future use as much as possible.

I agree with David. Furthermore, reflection can definately be used to initialize your application. I.e., at the startup of the application.

So, you shouldn't just throw away all your reflection code. But you should use it with care.
13 years ago
First, method variables are stored in the stack frame of your method. So every variable you declare will need a place in this frame. But when variables get out of scope in the method, this place can be used by an other variable that is declared further in the method.

Second, you should keep the scope of your variables as little as ^possible, at all times. If you don't do so, you might cause a STORE operation (for variables with a lifecycle larger than needed), and *that* would be a waste.

So, basically, it is better coding style to declare your variables in your for loop, and not outside. You should not trust the compiler to optimize your code since not all compilers will do so.

The same is true for iterators: you beter use:

for (Iterator=...

instead of:

Iterator iter = ...
while (iter.hasNext()) ...

13 years ago

Originally posted by let itbe:
- is EJB still worthed to learn? there is one book with title "... without EJB". I heard EJB to complex to implement and maintain. is Strut based on EJB?

EJB's is a technology like an other. EJB's give you an environment in which you can develop flexible and scalable applications. There are other methodologies, like Spring, that offer an alternative to EJB's. But both methodologies have there pro's and con's. I guess the biggest con with EJB's are the entity beans. But I think the EJB 3 specs will take care of that problem. Second, the EJB spec is quite a difficult spec with a big treshold for starters. But a well written EJB applications (with the common J2EE design patterns in place) should not be that hard to maintain. At least, not harder than other applications. So learning EJB will not be a waste of time.

Struts is a framework build on the JSP technology. Not on J2EE. Struts is often used as the view/controller tier of a J2EE applications, but it can also be used for any other java web appliaction. (You can use it on a Tomcat server for example)


is it possible to write an EJB-QL query that uses normal CMP entity beans, together with plain database fields (not wrapped with an e-bean).

With other words, I need to write a where clause that does something like this:

WHERE myBean.thingyFK.value = ?1

'myBean' is a normal entity bean and has a foreign key to a database table 'thingy'. From this table, I need the column 'value'. The table 'thingy' has no entity bean. (And it is not possible to introduce a new entity bean for this...)

Otherwise I'll have to use a fastlane or something, but at this point I rather want the EJB-QL solution.

Thanks a lot!
Since the stateful session bean already manages your transaction, you probably want to use POJO's behind it. On the other hand, you might want to use a stateless session bean before a bunch of entity beans to make a session facade. This way you keep your options open for possible clustering and distributing your project. You can make a facade with regular POJO's, but this will strap you to the same application server your stateful session bean is running. This is basically the same as Ilja Preuss said, but viewed from an other angle.

So depening on the appication lay-out, and the future expectations of your project, any of the two options is possible:

- One application server, no need to split up the application behind the statefull session bean, no need for remote access to the methods on the so called 'helper classes': definately POJO's

- Session facade wanted (this is a J2EE design pattern), remote access wanted, possibility to scale the application over multiple appliciation servers: stateless session bean will be the answer
13 years ago
The Java Docs state:

NOTE: The functionality of this interface is duplicated by the Iterator interface. In addition, Iterator adds an optional remove operation, and has shorter method names. New implementations should consider using Iterator in preference to Enumeration.

13 years ago

Originally posted by Ilja Preuss:
Can you show us the benchmark code?

Also, what JDK did you run this on? This might heavily affect performance differences.

I just took Krishna Srinivasan's code and cleaned it up a bit. I'm not sure what JDK I used at home. But I tried it again at work with JDK 1.4.2_03 (on a faster PC that at home). These are the results:

So, the -O option doesn't do much. The ratio of 5 times faster holds.

13 years ago
If you need to make a lot of threads over and over again, this will be very time consuming. So, you might want to create a thread pool in this case. This means, you keep a bunch of threads alive, and reuse them. But this is a bit more trickier that it seems, so you should inform yourself before doing so.
13 years ago
I know, this thread might be dead allready, but what the heck I tried it out for you. I ran both implementations 100,000 times and measured the time needed for this. The String implementation took 1.482 seconds to complete. The StringBuffer implementation took no more than 270 milli seconds to complete. This is more than 5 times faster than the String implementation.

13 years ago

Originally posted by Tim West:
So, it can be slower in multithreaded apps, but you might need synchronisation.

Synchronized code will always have an influence on the performance of your code. Even in non-multithreaded apps, the overhead can be significant.
13 years ago
In practice, Singletons should be avoided where possible. Singletons make it very difficult to mock your code, which makes it difficult to properly unit test your classes. A better solutions is inversion of control where you create your instance only once, and pass it forward to every method that needs it.

Singletons are often used for service locators. Service locators are java classes that manage 'services' (in fact any java class you want), and can force a singleton behaviour of your class, without the need of a real singleton implementation of your class. But even service locators can be passed by inversion of control...

And a little remark on the code Jason Fox provided. This code is not thread safe: the thread may be stopped right after the (s == null) test, before the creation of the singleton. So, from the moment you use this code in a multithreaded environment, you are not sure of the singleton behaviour. Making this code thread safe will require you to make the method synchronized. But synchronized methods are slow, and should be avoided in 'normal' code. So an other solution is to instantiate the singleton at the declaration of the instance field. This has the drawback that you will have an instance of the class from the moment the class is accessed for the first time. But most of the time the first access to a singleton class would be a getInstance() call, so this isn't such a problem.

[ June 28, 2004: Message edited by: Kris Philippaerts ]
13 years ago