Sati Sidhu

Hi Everyone,

My browser is sending the if-modified-since header in the request and the ibm http server/apache is striping it out of the request. However, if I pass the request directly to my application server(i.e. websphere) by changing the port number in the URL, I can see the if-modified-since header being passed to my servlet!

Does anyone know of any solution to this problem?

Thanks,

Satnam.

Hi there,

I am having the same problem! My browser is sending the if-modified-since header in the request and the ibm http server/apache is striping it out of the request. However, if I pass the request directly to my application server(i.e. websphere) by changing the port number in the URL, I can see the if-modified-since header being passed to my servlet!

Does anyone know of a solution to this problem?

Thanks,

Satnam.
[ February 11, 2005: Message edited by: Sati Sidhu ]

Thanks guys, I was also looking for the same answer.

Regards,

Sati.

Hi everyone,

I have discovered a discrepancy regarding message
acknowledgement using BMT message driven beans. On page 458 HF book,
it says:

"If the method throws a runtime exception, the message goes back on the queue"

According to the spec, it says:

"Message-driven beans should not attempt to use the JMS API for
message acknowledgment. Message acknowledgment is automatically
handled by the container. If the message-driven bean uses container
managed transaction demarcation, message acknowledgment is handled
automatically as a part of the transaction commit. If bean managed
transaction demarcation is used, the message receipt cannot be part of
the bean-managed transaction, and, in this case, the receipt is
acknowledged by the container."

..and according to Simon Brown's interpretation of the spec on
http://weblogs.java.net/blog/simongbrown/archive/2004/06/message_acknowl.html,
it says:

"So then, message acknowledgment is handled by the container. With
CMT, a commit or rollback will effectively acknowledge or not
acknowledge the message, but with BMT the message will always be
acknowledged. This is a subtle point but means with BMT that if the
onMessage() doesn't return successfully, the message gets acknowledged
anyway and redelivery won't occur. It seems that you have to be very
careful about implementing BMT message-driven beans!"

The Ejbplus exam simulator also backs this argument in one of the exam question anwsers.

"Since the onMessage() throws a systems exception each time it gets a message, it causes an infinite loop of delivering the message. Many application servers provide support for handing this kind of situation but if not checked, it can potentially bring down the appserver.
Also, rolling back the transaction is same as throwing a system exception because the message receipt will not be acknowledged.
Also remember that this happens only in the case of CMTs (not not for BMTs) because in case of a CMT MDB, the message acknowledgement is a part of the transaction (which gets rolled back) while in case of a BMT MDB, it is not. So even if a BMT MDB throws a system exception, the message is acknowledged.
"

Can anyone help clarify this discrepancy?

Thanks,

Sati

[ December 31, 2004: Message edited by: Sati Sidhu ]

[ December 31, 2004: Message edited by: Sati Sidhu ]

[ December 31, 2004: Message edited by: Sati Sidhu ]
[ January 01, 2005: Message edited by: Sati Sidhu ]

Kathy's reply to my question:

Howdy -- yes I think this is VERY confusing because of the way we
worded it. We should have added that this applies only to transactions
that START in the stateful bean, rather than the client.

For example, imagine a client calls a method on a stateful bean that is
marked with a transaction Required. The Container starts the
transaction, but the transaction MUST end when the method completes.
But using BMT, the stateful bean can start a transaction, but then not
close it at the end of the method (and instead wait for another method
invocation on a method that DOES end the transaction -- a really bad
idea).

Now, what was confusing I think is that you are right that if another
bean starts a transaction and THEN calls a method on the stateful bean,
and that bean is using CMT, then the bean that originated the
transaction does not cause the transaction to start, and so the
transaction can stay open while the originating bean keeps calling
methods on that same stateful bean.

So, that bullet point refers ONLY to transactions that originate in the
bean itself. A CMT transaction that begins with a bean's invocation
must *end* when that method completes. But a BMT transaction can be
started in one of the stateful bean's methods and then ended in a
different method of that same stateful bean.

Does that help?

Cheers and sorry about the confusion!

Sorry guys, but i'm still very confused with the following post:

Thanks Suman !
But I still feel that I'm missing something about CMT stateful beans here.
The API states that
"The afterBegin method notifies a session Bean instance that a new transaction has started, and that the subsequent business methods on the instance will be invoked in the context of the transaction. "

But in Head First EJB, it is said that "CMT transactions cannot stay open across multiple method invocations from a stateful session client."

Don't you find these statements contradictory ?

And the statement "Only stateful session beans can implement SessionSynchronization, because stateless session beans are not allowed to maintain a transaction once a method has ended."
seems to support the first statement and contradict the second.

Can you advice ?

Thanks so much
Vipin

Kathy can you please shed some light on this topic as your the person who wrote the first statement. I rather hear it from the horses mouth!

Can you also provide an example of the following statement in the spec:

If a session bean instance is participating in a transaction, it is an error for a client to invoke a method on the session object such that the transaction attribute in the deployment descriptor would cause the container to execute the method in a different transaction context or in an unspecified transaction context. In such a case, the container throws the java.rmi.RemoteException to the client if the client is a remote client, or the javax.ejb.EJBException if the client is a local client.

Thanks,

Sati