March 2007 - jboss-dev-forums - Jboss List Archives

[Design of JCA on JBoss] - Re: JDBC/XA changes to better support MSSQL Server

by adrian＠jboss.org

Obviously, you can only do it if statements are being tracked. Otherwise, the statement is not recorded or wrapped. The other part is whether this should be optional, i.e. you need to add a <cancel-statements/> since not all drivers need this check? The most optimal way of doing it (and also the most generic) would be store an "inExecute" reference count inside the WrappedStatement for the number of times the execute method is being invoked concurrently. This way we know whether the statement should be canceled. I think cancelling statements is a good idea in general anyway. e.g. If we are returning prepared statements to the pool we want to make absolutely certain it is not currently invoking on the db. But the latter part is probably just a debug feature for strange multi-threaded uses? e.g. servlets. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025520#4025520 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025520

19 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: JDBC/XA changes to better support MSSQL Server

by weston.price＠jboss.com

You beat me to the punch in posting it in :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025518#4025518 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025518

19 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: JDBC/XA changes to better support MSSQL Server

by adrian＠jboss.org

Original discussion: Problem: Need to invoke Statement.cancel() otherwise XAResource.rollback() blocks. anonymous wrote : | So basically we need to add something to the jdbc resource adapter | such that when XAResource.prepare(), commit(onePhase) or rollback() | or for local tx Connection.commit()/rollback() | is invoked, we check whether there are any currently "open" | statements and issue a cancel(). | | We already keep track of unclosed statements in WrappedConnection | so this should be a fairly trivial change? | | I guess also, that if a close() is going to block, | we should also do the same cancel() when we close statements | (or return the statement to the prepared statement cache) | in response to a close() on the connection wrapper. | and anonymous wrote : | I'm saying the JCA layer should do it | (in cases where the jdbc adapter doesn't do it itself). | | The stack would look something like this? | | org.jboss.resource.adapter.jdbc.WrappedConnection.cancelStatements(); | org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkComplete(); | org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.rollback(); | tm.handleTimeout(); | | Before doing the real delegation: | | com.acme.xadatasource.XAResourceImpl.rollback(); | org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.rollback(); | tm.handleTimeout(); | | The same feature would work for local datasources as well | since we give you a LocalXAResource that invokes the | ManagedConnection's local commit/rollback, i.e. | | org.jboss.resource.adapter.jdbc.WrappedConnection.cancelStatements(); | org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkComplete(); | org.jboss.resource.adapter.jdbc.local.LocalManagedConnection.rollback(); | org.jboss.resource.cm.TxConnectionManager$LocalXAResource.rollback(); | tm.handleTimeout(); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025517#4025517 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025517

19 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: JDBC/XA changes to better support MSSQL Server

by weston.price＠jboss.com

In looking at this there are a few things to consider: 1)We would have to do this for all handles registered with the XA/Local MC 2) The only way this would really work is if they are using the track statements, being that this is the only condition where we register and keep a *memory* of currently executing statements. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025507#4025507 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025507

19 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - JDBC/XA changes to better support MSSQL Server

by weston.price＠jboss.com

Continued discussion View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025490#4025490 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025490

19 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: JMX Notification support

by adrian＠jboss.org

The simplest implementation is to just extend NotificationBroadcasterSupport which will be picked up when you introduce the JMX aspect. But as you say, this type of thing should really be done with an AOP introduction. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025484#4025484 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025484

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by scott.stark＠jboss.org

Put it in the mc trunk and we'll figure out what to do with the what get merged to/from the 2.0 branch after the jboss5.beta2 release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025483#4025483 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025483

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by adrian＠jboss.org

Since we are now "intercepting" the controller actions, this should be something that can be applied to any context, not just POJO. As such, the api should be the more generic: org.jboss.dependency.plugins.spi.action.ControllerContextAction rather than KernelControllerContextAware. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025481#4025481 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025481

19 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGiControllerContext design

by adrian＠jboss.org

I don't understand your questions without more details or something more concrete to respond to? Let me give you my simplistic mapping of the api (the devil is always in the details which are not included here). The OSGiControllerContext is an implementation of the OSGi component model the "service layer" of the OSGi core. The bundle context is an OSGi personality (as Sacha called it :-) of the JBoss Deployer's DeploymentContext. The "on the fly" part is where we "morph" a JMX or POJO deployment to look like a OSGi Bundle. We could also do other deployment types but the others like ejb or war components map less well as OSGi services. Certainly, the classloading could be integrated for all deployment types if they are using an OSGi style classloader. The bundle activator is like our MainDeployer, but it also has features relating to the profile service, i.e. programmatic activation of bundles (deployments) from the repository which is more related to our profile service. Like I said above, the devil is always in the details, and you are almost certainly going to have to implement additional features in the JBoss Deployers so you can hook in the OSGi personality, not least the classloading, but also notifications, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025470#4025470 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025470

19 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM Multithreading: Is there a specification?

by archer77

It seems that I've caused some misunderstanding (or perhaps I don't understand correctly). I do not have process forks and joins in the process defninition, my jBPM just runs one linear process definition. To simplify testing even more, there is just one process instance available a time (process id = 1). The problem is that two threads can interact with the process instance by calling some method on the jBPM core. Since these calls come from completely different directions, they cannot share the execution context (would be a security issue also), they have to rely only on the deterministic behaviour of the jBPM, including defined synchronisation behaviour. As I understand it this problem should also exist in other setups e.g. jBoss SEAM framework with jBPM in the background, where multithreaded jBPM access occurs from different tomcat-webserver threads, but since these frameworks are comparatively slow, time-race conditions with vulnerable interval of 1-10ms or even less will not occur frequently. Perhaps the central question is: Is it allowed to access jBPM methods or objects from two different threads or do I have to build a "synchronized" cage around the whole jBPM to make sure that only one request is executed a time. (Still I'm not sure if this would really solve it since the jBPM includes timers which I guess are implemented as separate threads that could also cause the time-raze conditions). BTW: If useful, I could try to setup a system with full persistence, but I guess that the problem won't be solved that way (unless the desynchronisation is due to broken lock handling in the underlying hibernate code or the in-memory database implementation). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025457#4025457 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025457

19 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2007