Gouri Bargi

Ranch Hand
+ Follow
since Sep 29, 2002
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Gouri Bargi

Hi,

I have hardly any experience in JDBC programming. I am developing an application where daily 200 to 300 records are to be uploaded to DB2 UDB version 8.1 database, at one go. I am thinking of using the batch updation methods provided in JDBC 2 - Statement.addBatch and Statement.executeBatch. Is it a good idea to have hundreds of insert queries in a batch? Is there some more efficient way of uploading this data through java? How much data can I send in one go? Where can I find information regarding usage of these methods?

- Gouri
Congrats!!! 92% is a great score.

- Gouri
Hi Santosh,

I am interested in purchasing the voucher, if it is valid till 15th november.

Gouri
Hi Narasimha,

As mentioned on page 682 of HFSJ there are 3 steps in the implementation of doFilter method:

1. request filtering, before call to chain.doFilter
2. call to chain.doFilter(), which will call any other filters and the servlet.
3. response filtering after call to the servlet. At this point, we have already written something to the OutputStream of the response object passed to the service method (The OutputStream returned by response.getOutputStream). If this is the actual ServletOutputStream, then whatever we wrote is already sent back to the client. (As described on page 683, HFSJ). In this case, the response is already sent to the client, and there is no use filtering it now.
To avoid this, we ensure that the OutputStream available to the service method is not the ServletOutputStream of the response. We pass a wrapper object (HttpServletResponseWrapper) implementing HttpServletResponse to the call to chain.doFilter(), not the original HttpServletResponse. The getOutputSTream() method on this wrapper will return a different OutputStream - (may be a ByteArrayOutputStream??), not the ServletOutputStream. That means when the OutputStream received from the response wrapper is flushed, the response is not sent to the client. And when the flow of control returns to filter1, we have the data in the wrapper's OutputStream, and the actual response object to which we want to write this data. The compression / filtering is done, and then the data is written to the actual response OutputStream.

- Gouri
Hi Nicky,

<ejb-ref-name> and <ejb-ref-type> are inside <ejb-ref> or <ejb-local-ref> elements. There are some additional elements for ejbhome / local home and remote / local interface information in these elements. You will find the deployment descriptor DTD in servlet specs.

- Gouri
Hi Vijaya,

You are right - getAttributesScope(String) method is also present in JSPContext.

- Gouri
Hi Vijaya,

Please check the HFSJ errata. The explanation of option E and F has got interchanged.

- Gouri
Hi,

A trick to remember which event listeners to register in the DD :

The listeners can be classified in 2 categories:

1. Those that are interested in all events of one type(e.g. HttpSessionListener (interested in ALL Http session creation and destruction events), HttpSessionAttributeListener(interested in all session attribute events - any attribute added / removed / replaced), and all the listeners for ServletContext and ServletRequest.

The container creates one instance of each of these listeners.

2. Those that are interested only in specific events of one type. (there are 2 listeners of this type - HttpSessionBindingListener (interested in knowing when it is itself bound / unbound to a HttpSession) and HttpSessionActivationListener(interested in knowing when only the session it is bound to is activated or passivated, so that it can prepare itself for activation / passivation)

We create the instances of these listeners and set them as attributes in specific http sessions.


The first type of listeners are configured in the DD - as their methods are ALWAYS called when the event occurs.

The second type of listeners are not configured in the DD.

On page 262 in HFSJ, it is mentioned that HttpSessionActivationListener interface may usually be implemented by an attribute class or some other class. I think this is not correct - HttpSessionActivation should always be implemented by an attribute class.
- Gouri
[ September 27, 2005: Message edited by: Gouri Bargi ]
Hi,

Perhaps the interviewer wanted to know the disadvantages of the servlet chaining as it was in the pre-servlet specs 2.3 days - without filters, when the servlet chaining mechanism was non-standard, server specific. The introduction of filters provided a standard, powerful and easily configurable alternative for the old "servlet chaining".

- Gouri
Hi,

My answer would be A, D and F. I think answer C is also wrong - the variable ctx here is not thread safe. There will be one ServletContext for one web application. That means, if there are more than one servlets in the application, they all share the same ServletContext object. Synchronizing access to SErvletContext in one servlet will not guarantee that the SErvletContext object is thread safe.

I am also not able to understand the explanation


obj is not thread safe because even though the ServletContext object is synchronized, its attributes are not. They need to be synchronized separately.



I think obj is an attribute set to the ServletContext, and can be accessed from all the servlets in the web application, hence it is also not thread safe.
Hi,

I am confused about what the load on startup values indicate.

What do 0 and negative values indicate?

I remember setting load on startup value to -1 in websphere for loading a servlet at startup. Is it a websphere specific feature?

- Gouri