Geoff,
It IS fixed in 1.5.4, so please let us know what fails for you.
Here is a sample setup:
1. Set up and start SwiftMQ.
2. In your /config/application.xml have a setup like the following:
SwiftMQ resource provider.
3. Start Orion, deploy the ATM sample (it uses a MDB with a t
Hi Russ,
What exactly do you mean by "stored/retrieved"? Is there a reference in
the spec you can point out?
Cheers
Geoff
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Russ White
Sent: Monday, 18 February 2002 11:47 AM
To: Orion-Interest
Subject: R
Well, I just tested an MDB with SwiftMQ, and Orion still stuffs up the
message ordering. Presumably this means it's broken in the MDB
implemenation rather than in Orion's JMS code, which is a pity.
So, for all those using Orion MDBs, and relying on message ordering
being preserved (if there are
FYI, this was not fixed in 1.5.4.
Naughty Magnus! :-)
Geoff
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Ray Harrison
Sent: Monday, 14 January 2002 8:50 AM
To: Orion-Interest
Subject: Re: A word of warning: SwiftMQ and Resource providers.
Accord
Yes, they should be received in order, but not necessarily stored/retrieved in
order.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Geoff Soutter
Sent: Sunday, February 17, 2002 5:18 PM
To: Orion-Interest
Subject: RE: fyi: 1.5.4 still stacks rather than
Hi Mike,
I didn't see that comment. Unfortunately this list is so flakey that I
only get about 75% of the messages.
I just checked the JMS 1.02 spec, here's what it has to say about
message order (in 4.4.10.1 Order of Message Receipt):
"JMS defines that messages sent by a session to a destinat
EntityBean with BMP and Local/LocalHome etc. Doesnt
compile, some internal error...
Does anyone have an idea of what could be the
cause of the error?
/David
Auto-unpacking
E:\cygwin\usr\local\java\orion\applications\app.ear... done.Auto-unpacking
E:\cygwin\usr\local\java\orion\applicat
CachedRowSet doesn't participate in transactions as it is "teared-off"
object and it stores stale (old) data. For high-volume concurrent updating
requests use it with care ( or better not to use if you are not sure ).
I use it for read-only data infrequent access.
-Original Message-