Answering my own post...does that count as talking to yourself ?!?
Ok, I've made a bit of progress with this.
This post was of immense help:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=74475
By incorporating the suggested changes into
deploy\ejb.deployer\META-INF\jboss-service.xml, S
Environment: JBoss 4.0.5.GA, Sun JDK jdk1.5.0_11
| C:\Paul\Projects\SSL-EJB\bin>run.bat -c ejb-server
|
===
|
| JBoss Bootstrap Environment
|
| JBOSS_HOME: C:\Paul\Projects\SSL-EJB\bin\\..
|
| JA
ok...I took a step back and tried option 1 from above:
http://docs.jboss.org/jbossas/jboss4guide/r3/html/ch8.chapter.html#d0e20905
I now have a more managable issue (I think)
The client is now giving me the dreaded
javax.net.ssl.SSLHandshakeException:
I followed the instructions above to create t
I'm trying to bind an EJB service to support SSL only invocation.
I'm running the following configuration:
JBoss 4.0.5.GA
Sun JDK 1.5.0_11
Windows XP / Solaris 9
In my case, the client is another JBoss server of the same configuration.
There seems to be two completely different methods to impleme
"timfox" wrote : "paul_da_programmer" wrote : If the JMS implementation is an
XA compliant one, even without persistence then the answer is yes.
|
| Yes. But this has got absolutely nothing to do with whether JBM persists
non persistent messages or not.
I guess that re
"timfox" wrote : If you are using only non persistent messages, then there is
nothing to "back out" from the DB, since nothing has been saved to the db.
|
| Perhaps I don't follow what you are trying to say...
What I want to back out (or commit atomically) is the XA DB work that my biz
func
I'm only interested in the ATOMIC ('A' in ACID) aspect of a transaction. What I
want to guarantee in using a JMS in a NONPERSISTENT mode is that if the JMS
transaction ends abruptly, that all DB work will be back out ATOMICALLY (i.e.
all or none)
That's why I asked if there is a configurable wa
So would non-persistent messages still preserve the transactional integrity of
the JMS transaction?
onMsg(...) {
|//performSomeDBOperation( ) // or any XA transactional operation
|...biz throws an uncaught exception which is propagated to the JMS
container
| }
|
Can I assume th
On the surface that makes sense, but I do want the security (ie the
transactionality) that using Oracle offers for my application. In other words,
the consumers of the message also update Oracle data, so I want the 2PC
transactionality of (ACK of JMS message == updates were performed). If I don'
FYI, I duplicated this message on the "other" messaging forum:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=109187
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4047570#4047570
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=pos
Due to the constraints of my application, there isn't any need for me to
preserve messages in a Queue when the application is bounced. As a matter of
fact, persisting them across reboots will have the undesired effect of
initiating a flurry of activity when the server comes online when all of th
Sorry, I should say that I'm using Oracle as the persistence provider as well.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4046858#4046858
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4046858
Due to the constraints of my application, there isn't any need for me to
preserve messages in a Queue when the application is bounced. As a matter of
fact, persisting them across reboots will have the undesired effect of
initiating a flurry of activity when the server comes online and all of the
13 matches
Mail list logo
