[Design of Messaging on JBoss (Messaging/JBoss)] - caching xa resource on the client side.
by ataylor
This is regarding https://jira.jboss.org/jira/browse/JBMESSAGING-1298
Currently we make all calls as blocking when we wouldn't need to if we cached some of the state on the client side. I've gone through the methods to see which ones we can make non blocking as follows:
Blocking
void commit(javax.transaction.xa.Xid xid, boolean b)
void rollback(javax.transaction.xa.Xid xid) throws javax.transaction.xa.XAException;
int prepare(javax.transaction.xa.Xid xid) throws javax.transaction.xa.XAException;
for obvoius reasons all these need to be blocking.
int getTransactionTimeout() throws javax.transaction.xa.XAException;
needs to be blocking as we return the timeout.
javax.transaction.xa.Xid[] recover(int i) throws javax.transaction.xa.XAException;
again we're returning values so needs to be blocking
non blocking
void start(javax.transaction.xa.Xid xid, int i) throws javax.transaction.xa.XAException;
this can be non blocking. It never throws an exception and it doesn't matter what flags are passed.
void end(javax.transaction.xa.Xid xid, int i) throws javax.transaction.xa.XAException;
If the xid passed in is *not* the xid of the tx currently associated with the session then we need to do this non blocking as we need to throw an exception if it doesn't exist or is not suspended.
If the xid is the xid of the currently associated tx and is being called with success or fail flags then we only throw an exception if the tx is in a suspended state. Since we can check this state on the client side we can do this non blocking. If the suspend flag is passed then again we only throw an exception if the tx is already suspended which again we can check on the cliet side.
void forget(javax.transaction.xa.Xid xid) throws javax.transaction.xa.XAException;
currently forget doesn't actually do anything apart from set the state so this can be non blocking.
boolean setTransactionTimeout(int i) throws javax.transaction.xa.XAException;
this always returns false so can be done non blocking.
boolean isSameRM(javax.transaction.xa.XAResource xaResource) throws javax.transaction.xa.XAException;
this is already client side.
Code change will basically just holding state on the client side and moving some of the error handling to the client.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206881#4206881
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206881
15 years, 4 months
[Design of JBoss Identity] - comments on IDM 1.0-alpha1.
by jeff.yuchang
I am trying to use the IDM in the guvnor, it looks great, while here are some comments.
1. Currently, the idm module has two implementation out of box, one is db, the other is ldap. I am wondering will it be better if we split it to two modules, say idm-hibernate, idm-ldap etc. so that people can just use what they want.
2. In the db scenario, I have found that we need to have the persistence.xml in the META-INF/ folder, and in the persistence.xml, we have listed a set of implementation classes. I am thinking that can we hidden those implementation classes to users somehow. such as we can have a default persistence.xml(or other name) that contains the inner implementation class in the idm-hibernate module. while for the users, they just need to configure the database connection.
thoughts?
Thanks
Jeff
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206873#4206873
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206873
15 years, 4 months
[Design of EJB 3.0] - Re: WARN logs in InterceptorRegistry
by jaikiran
I have started work on fixing this. One of the issues (though not directly related) i see in this registry, is this:
| Class<?> beanClass = advisor.getClazz();
| for(Method beanMethod : ClassHelper.getAllMethods(beanClass))
| {
| interceptorsAnnotation = (Interceptors) advisor.resolveAnnotation(beanMethod, Interceptors.class);
| List<Class<?>> methodInterceptorClasses = new ArrayList<Class<?>>();
| if(interceptorsAnnotation != null)
| {
| for(Class<?> interceptorClass : interceptorsAnnotation.value())
| methodInterceptorClasses.add(interceptorClass);
| }
|
| ...
>From the EJB3 spec:
anonymous wrote : Interceptors are used to interpose on business method invocations and lifecycle events that occur on an enterprise bean instance.
So, using
ClassHelper.getAllMethods(beanClass)
doesn't look right.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206865#4206865
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206865
15 years, 4 months
[Design of JBoss jBPM] - Re: db properties reorg
by heiko.braun＠jboss.com
anonymous wrote :
| Ideally i would like to move to the following situation:
|
| * a config module that has the default persistence configuration and produces it in a jar file in the repo.
|
right, that something we agree upon. Just that the current configuration resides with the jpdl module which produces a a config jar that goes into the repo: jbpm-jpdl-4.0.0-SNAPSHOT-config.jar
Another requirement is to switch between hibernate managed connections (simple tests, jdbc properties) to container managed connections (intgeration tests, datasources). This is something we already did in jBPM3
and I simply wanted to leverage the existing build, which is non trivial.
Hence the change from hibnerate.cfg.xml+hibernate.properties to a single hibernate.cfg.xml which includes the connection settings.
So basically, the db.properties (i.e. mysql.properties) disappeared and have been replaced by hibernate.mysql.cfg.xml, which ship with the jpdl-config.jar.
Currently this get's expanded into every module that needs db connection settings and is used by the installer to finally create hibernate.cfg.xml and *-ds.xml for deployment into the AS.
The build is driven by profiles.xml which contains the connection properties (i.e. Qa on your local box vs. jboss QA environment) and by the 'mvn -Ddatabase=mysql' switch, that defaults to hsqldb.
Does that answer your question?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206862#4206862
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206862
15 years, 4 months
[Design of JBoss jBPM] - db properties reorg
by tom.baeyens＠jboss.com
heiko,
can you explain the purpose of the reorg of the db properties? i couldn't find what was extra things became possible. probably there is some aspect that i didn't get.
ideally i would like to move to the following situation:
* a config module that has the default persistence configuration and produces it in a jar file in the repo.
jbpm configuration would contain a reference to hibernate.cfg.xml *and* hibernate.properties
hibernate.properties would contain the hypersonic in memory configs.
* the db module approx as it was: containing ${database}.properties files for all the db's
in the parent pom, there is a section that takes the specific database properties file, resolves the properties and overwrites the default hibernate.properties with it.
------------------------------------------------------------------------
do you see problems with this approach ? things that would be invalidated that you've build just now ?
the difference between how it was originally is that by extracting the default configs in a separate module, we remove the necessity for each module to have its own configuration files in the resources. so we can prevent spreading copies all over the code base that have to be kept in sync.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206858#4206858
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206858
15 years, 4 months