Osuwari Inu

I know this is an ancient post, but I just made a small script to recursively explode an ear/war/jar/zip and thought it might be of use to someone finding this thread.

#!/bin/sh
#

if [ ! "$1" ];
then
echo No ear file specified.
exit 1
fi

if [ ! -f "$1" ];
then
echo Specified file does not exist or is not a file.
exit 1
fi

if [ ! "$2" ];
then
echo No destination directory specified.
exit 1
fi

if [ ! -d "$2" ];
then
echo Destination directory does not exist or is not a directory.
exit 1
fi


unzip "$1" -d "$2"
find "$2" -type f -name "*.war" -exec mkdir "{}.exploded" ';'
find "$2" -type f -name "*.war" -exec "$0" '{}' "{}.exploded" ';'
find "$2" -type f -name "*.jar" -exec mkdir "{}.exploded" ';'
find "$2" -type f -name "*.jar" -exec "$0" '{}' "{}.exploded" ';'

The solution is to either use bean-managed transactions, or to break the send and receive into two separate methods.

And then set a REQUIRESNEW transaction attribute on the receive method!

Oh and one other fun detail I found out after we deployed the application on WebSphere on AIX. Specifying a negative timeout (bug in my own round robin receive algoritm) on Windows would result in an IllegalArgumentException, whilst on AIX it would be interpreted as 0 (block indefinitely). A minor but _very_ annoying detail.

Be warned

So basically your problem is:
How do I delete a large amount of rows using beans?

Sorry, my bad. Just found out that this forum ignores leading blanks

Good question. My instinctive response was: "Ewww NO!". But to be honest, I cannot really think of a reason why it should not be done. (Passing the connection as a variable from a publicly accessible method to private 'handling' methods doesn't sound too bad. I realised I do it myself in the following scenario:

.public DataObject gimmeA()
.____throws SQLException
.{
.____Connection c = null;
.____PreparedStatement pstmt = null;
.____ResultSet rst = null;
.____String query = "some query defined somewhere in a central location.";
.____try {
.________c = acquireConnection();
.________pstmt = c.prepareStatement( query );
.________rst = pstmt.executeQuery();
.________if ( rst.next() ) {
._____________return readDataObject( rst );
.________} else {
._____________return null;
.________}
.____finally {
.________closeDBStuff( c, pstmt, rst );
.____}
.}

The closeDBStuff method attempts to close any given non null pointers. I use this method to avoid tedious code duplication of trying to close something and reporting upon error.

The readDataObject type methods allow for some code reuse if one has to load different sets of data objects of the same type. (I.e. all users of a group, or users of a group including all the users in all the subgroups).

Hope I didn't duplicate part of a previous discussion

(Sheesh indentation is a bitch )
[ July 07, 2005: Message edited by: Osuwari Inu ]

i cant read this code please use interpunction in your questions and indent your code i doubt you will find anyone willing to try to help you if you drop it on them in a condition such as this i actually find it hard to type without any markup whatsoever i mean how do you do it?

Oh dang! I actually used a questionmark there.

The code seems ok. I'm guessing the problem is the same one I used to have way back.
Have you tried adding some debugging statements to your code? If you put them in the correct places I think you might see something not quite unlike the following scenario:
- Session bean: Sending message
- Session bean: Waiting for reply
- Session bean: Timed out waiting for reply
- MDB: Received message
- MDB: Sending reply
- MDB: Reply sent

What happens here is that both the send and the receive in your test code are done in the same transaction. If the send method does not throw an exception, that only means that the transport layer has accepted your message, not that it has actually been sent. (The mail is in the mailbox).
For the message to be sent, the current transaction has to complete succesfully. Which is done (at the earliest) after sendRecvMessage is finished.

The easiest way to solve this problem and make your test case work, is to give the receive (getMessage) method a transaction attribute of RequiresNew. This will start a new transaction, closing the previous one, allowing the message to be send.

Some constructive criticism: (or: things you didn't ask for )
In stead of looping like:
for(int i=0;i<100000;i++);
to wait for a small period, use:
Thread.sleep( 100 ); // in milliseconds

This will not cost cpu time. The looping for time is really ASM/Pascal age

Try closing things in the opposite order of opening:
Open connection
Open session
Close session
Close connection

This may avoid unexpected exceptions and generally is considered good coding practice.

Hope this helps

Just some more questions, in the hope they may lead you to an answer

Do you use entity beans? Do the servers run in commit option A? I.e. do they cache the data?
Do you browse the messages on the queue? Or do you browse the persisted messages?

Let me apologise beforehand for the length of this post: I'm sorry

Introduction:

I'm currently working on a project that relies heavily upon Websphere MQ as a JMS provider to send messages from our WebSphere application to mainframe applications and back.
We have just about everything working quite nicely, including ASCII<->EBCDIC conversion.

The problems start when the messages send by the mainframe application get over 32k in size, since the PL/1 applications cannot process data over 32k in size.
JMS has two possible ways to solve this problem: message segmentation and logical message groups.
The first (segmentation) is simply not supported on the IBM z/OS platform (http://www.developer.ibm.com/tech/faq/individual?oid=2:81777), so logical message groups automagically became our solution.

With logical message groups, the sender sends multiple messages, indicating in each message that it is part of a group and what the sequence number of that part is. When the application sends the last message, it uses a special flag while submitting the message to indicate that this was the last message in the group.

Problem description:

Since the software on the mainframe is written in PL/1, it is limited to
32k messages. As we have logical messages that are larger than 32k
(using xml-ish syntax), we need a way to 'segment' the messages. As I
understand it, there are two options available to realise this:
- 1 - MQ controlled segmentation. Apparently (according to IBM
documentation on the web (
http://www.developer.ibm.com/tech/faq/individual?oid=2:81777
)) this is not
possible on z/OS: "WebSphere MQ for z/OS does not support segmentation, but
it supports logical message groups."
- 2 - Application controlled 'segmentation' using message groups where each
message group consists of a single 'logical' message.

This second option was used succesfully for a short period on AIX. (It
still functions correctly on the Windows pre-test environments. (Same ear
file)). We have no idea (yet) whether that was mere coincidence or whether
something in either the MQ or the WebSphere configuration was changed,
causing the current implementation to fail. At the time of writing every
attempt to receive grouped messages (this way) failed.

Current implementation on the WebSphere side does the following:
Receive a message (using a timeout period of several seconds).
- On error, report. On success read the JMSXGroupID message property to
determine whether this is a grouped message.
- If not, return the message received. If it is, store any and
all messages matching the correlation id set on the previously received
message (using the same receiver instance by calling the receiveNoWait
method until it yields no more results).
- Compile the complete message and return the result.

There is an assumption in this way of handling grouped messages that the
receive method, used to receive the original message, does not return a
message until all the messages in the group are available. Apparently this
is either an incorrect assumption, or it can be configured somewhere and
its setting has recently been changed.

As I see it, MQ (the transport layer) has all the information it needs to
successfully deliver either the entire group of messages, or not a single
one, and only signal the receiving queue manager when all messages have
arrived.
I believe JMS support for message groups is lacking one of two things here:

- 1 - JMSXGroupLast property (or something similar), or
- 2 - JMSXMaxGroupSeq property (or something similar), set on each message
to indicate the sequence number of the last message in the group.

Either option would allow the receiving application to successfully
recompile the original message.

After some deliberations, we set out on the following workaround:
When a received message is determined to be one of a grouped message, all
subsequent messages are received using a shorter (1 sec) timeout. As soon
as we receive the first timeout, we assume that all messages in the group
have been received.
Of course there is no guarantee that all the messages have been received
and the total wait time for the message has been extended by a minimum of 1
second, but at least this seems to get the job done for now.

Another option that does not rely upon a timeout is to check the actual
data for the end of the message, but that would mean crossing the
transport/application layer boundary, which I would rather not do.


These are the questions I asked IBM:
Question A: Am I correct in assuming that the receive method should not
return a grouped message until all messages in the group are available?
Question A-2: If not, what method (using JMS), could I use to determine
that all messages in the group have indeed been received? There appears to
be no standard (or IBM specific property on a message to indicate that it
is the last in a group). I know that there is in fact a flag in the MQMD to
indicate this.
Question B: Do you have a better way of receiving the remaining messages?
Or
Question B-2: Is this the way other customers have implemented receiving of
message groups as well?

I won't post the reply I got from IBM. Suffice to say it made me and and gave me the feeling of .

Apparently I asked some extremely difficult questions. Any comments? Ideas? Suggestions? Similar experiences?

For the original post I would recommend rethinking the problem, and whether it really is a problem with the software or the chain of thought.

With a basic receive reply where one sends a message and needs to wait for a reply, I recommend listening with timeout (without is dangerous) for a reply, using the id of the request message as the JMSCorrelationID in a message selector. This works fine for us.

I'd advise against using static variables in any J2EE application. It's a sure way to undermine scalability and caching in the server.
You could try to create a connection in the ejbCreate method of the MDB and release the connection in the ejbRemove.

JMS is by design asynchronous so the described behaviour, although clearly not intended, is valid.
If you want the messages processed in order you would need to either build your own synchronisation mechanism, or make the individual messages part of one large message.

Think about it this way: you have five message processors and you want all of them to wait until the messages prior to that particular one have been processed. Sounds like sequential processing to me.

Short answer: no, it is not possible.
Long answer: it might be.

JMS is asynchronous by design. It is likely that messages are received in the same order as they are send, but by no means guaranteed.
Depending on the underlying transport service (e.g. WebSphere MQ) it may be possible to configure it to always deliver the messages in sequence. But one would have to take care that priorities on messages remain the same.

If you need several messages to be processed in order, as in all or none, you might consider logical message groups.