[JBoss Microcontainer Development] New message: "Re: JBDEPLOY-226 - DeployerClient change extension"
by Adrian Brock
JBoss development,
A new message was posted in the thread "JBDEPLOY-226 - DeployerClient change extension":
http://community.jboss.org/message/527985#527985
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
alesj wrote:>
> > since I want to be able to do this as well in some of the stuff I'm doing.
> Related to JBKERNEL-54 / JBOSGI-151? :-)
I don't see why resolving circular dependencies needs this feature?
The problem with Thomas's implementation (if it is like what he has done elsewhere)
is that he is doing a checkComplete() too often.
He should check them all at the end, not during/after every single move. :-)
No, it is to implement the refreshPackages() behaviour when using shutdownPolicy=GCI'm implementing it properly inside org.jboss.classloading.spi.dependency.ClassLoading
where none OSGi users can use this feature as well.
It's not strictly required, but width first processing of deployments is preferable for a
number of reasons.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527985#527985
14 years, 11 months
[JCA Development] New message: "Re: feedback on JBAS-7195 (WrappedConnection.checkTransactionStatus throws exception when transaction is marked for roll back)"
by Adrian Brock
JBoss development,
A new message was posted in the thread "feedback on JBAS-7195 (WrappedConnection.checkTransactionStatus throws exception when transaction is marked for roll back)":
http://community.jboss.org/message/527970#527970
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
I don't think you'll break anything, but you'll lose the early notification of the failure.
i.e. in a lot of cases you'll be doing useless work which won't fail until it becomes time to commit/rollback.
That's cpu and resources that could be used by something else.
Perhaps you could make it an option in the -ds.xml instead?
The check was added to avoid sql operations leaking into the next transaction because of a race with the tx timeout.
This won't happen if the transaction is just MARKED rolled back only. The transaction hasn't completed yet.
See JBAS-5080, the race goes something like:
a) Thread 1: start running a query
b) Thread 2: timeout -> roll back transaction, which ends the local jdbc transaction
c) Thread 1: original query now reaches the real connection which is in a new local jdbc transaction as far as the jdbc driver is concerned
(b) hasn't happened if the JTA transactions is marked rolled back only
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527970#527970
14 years, 11 months