Woops. My CVS was a couple days out of date. I should have updated before
posting just to be sure. My mistake - sorry for the confusion.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872607#3872607
Reply to the post :
http://www.jboss.org/index.html?mod
??? I think you are looking at the wrong dtd?
http://cvs.sourceforge.net/viewcvs.py/jboss/jbosscx/src/resources/dtd/jboss-ds_1_5.dtd?r1=1.1.2.4&r2=1.1.2.5
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872592#3872592
Reply to the post :
http://www.jboss.org/i
I see ha-xa-datasource on the wiki but not in the jboss_ds DTD. Is it valid?
If it is, the DTD should be updated so I can generate the schema diagrams for
the book.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872587#3872587
Reply to the post :
http://w
Go ahead.
Raise some new tasks in JIRA for any improvements you think should be made
in future versions (including integrating the HA behaviour with the main RARs).
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872568#3872568
Reply to the post :
http://www.
It seems like all is done. Should the issue be closed?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872476#3872476
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3872476
--
Just copy the rars to docs/examples/jca
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872384#3872384
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3872384
---
SF em
"[EMAIL PROTECTED]" wrote : Do you have it documentated somewhere on the WIKI
(as experimental)?
| http://www.jboss.org/wiki/Wiki.jsp?page=JBossJCA
Yes, http://www.jboss.org/wiki/Wiki.jsp?page=JBossJCADatabaseFailover. It's
linked from the main JCA page under 'Database failover' in the Feature
Adrian, what else should be done here for the 4.0.2 release?
The XA HA stuff is only in HEAD currently.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872173#3872173
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=387217
"[EMAIL PROTECTED]" wrote : What's the issue with adding Derby to thirdparty?
The issue is actually to take care of it :)
"[EMAIL PROTECTED]" wrote : Or even writing a mock XADataSource?
That's what I'll do probably.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtop
"[EMAIL PROTECTED]" wrote : The XADataSource should just be a factory, it
should be the connections that are the
| heavy weight objects.
| I'd guess this is the usual "You don't pay for what you don't use"
| philosophy that JBoss normally does.
I could also instantiate them lazily. But the
"[EMAIL PROTECTED]" wrote : You need to identify which of the xadatasource
properties identifies the server,
| e.g. for mssql it is "ServerName"
|
|
| | ServerName
| | |
| |
|
Done.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872189
What's the issue with adding Derby to thirdparty?
Or even writing a mock XADataSource?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872182#3872182
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3872182
--
The XADataSource should just be a factory, it should be the connections that
are the
heavy weight objects.
I'd guess this is the usual "You don't pay for what you don't use"
philosophy that JBoss normally does.
It looks like the only change you made to the existing stuff was to make
the xa props
You can't just have
You need to identify which of the xadatasource properties identifies the server,
e.g. for mssql it is "ServerName"
| ServerName
| |
|
This is not an issue for local since the connection url is always in the same
config.
View the original post :
http://www.jboss.org
I've got first HA XA tests passing. Here is the ha-xa-datasource configuration
I used for testing
|
| XADerbyDS
|
| false
|
|
org.jboss.test.cmp2.advanced.ejb.DerbyXADataSource
| derby/hatest1|derby/hatest2
| sa
|
| creat
"[EMAIL PROTECTED]" wrote : It seems to be logical to be able to specify
user/password per URL instead of using the same user/pwd for every url in the
list?
|
| Then, as for me, it would make sense to still configure the ha datasource
as a collection of datasources. Not using all the elemen
"[EMAIL PROTECTED]" wrote :
| Should I be warried about thread-safeness of the whole implementation?
Yes, the pool allows multiple threads to be dealing with connection
construction/validation
at the same time, upto the max-size which is the basis for the semaphore.
View the original post :
What about the introduction of the new ha-local-tx-datasource element?
We could probably do some XSL tricks (like check whether url-delimeter is
present and connection-url actually contains more than one url) and avoid the
introduction of a new element.
View the original post :
http://www.jboss
It seems to be logical to be able to specify user/password per URL instead of
using the same user/pwd for every url in the list?
Then, as for me, it would make sense to still configure the ha datasource as a
collection of datasources. Not using all the elements that are usually used to
configur
Now URLs are selected with sticky round-robin algorithm. This is done in
URLSelector which is an inner class of HALocalManagedConnectionFactory.
Should I be warried about thread-safeness of the whole implementation?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic
"[EMAIL PROTECTED]" wrote : Also I didn't mention that it requires checking the
validity of the connection before it is given to a caller. In the testcase, I
use check-valid-connection-sql for that.
This is true regardless of HA.
JDBC has no mechanism to signal a broken connection asynchronously
"[EMAIL PROTECTED]" wrote : What about the introduction of the new
ha-local-tx-datasource element?
| We could probably do some XSL tricks (like check whether url-delimeter is
present and connection-url actually contains more than one url) and avoid the
introduction of a new element.
Yes, but
The testcase for this issue is added
| package org.jboss.test.jca.test;
| public class HAConnectionFactoryUnitTestCase
|
It's based on the HSQLDB. Also I didn't mention that it requires checking the
validity of the connection before it is given to a caller. In the testcase, I
use check-v
For a full implementation, I would like to see this exposed as a policy
such that the deployer can choose the failover policy
(and potentially load balancing policy if the db supports it correctly).
This will require not just checking for errors at connection construction time,
but also tracking f
For the initial implementation, I would like to see the connectionURL
remain sticky until it needs to failover.
That will reduce the problem of inconsistency where the replicating database
has some latency in its replication or does not fully support distributing
locking
(maybe only commit time le
25 matches
Mail list logo
