jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: mt-issues with org.jboss.tm.TransactionLocal

[<ad...@jb...>]

"bil...@jb..." wrote : 
  | I understand that, but we do control the implementation of 99.99999% of used TransactionLocalDelegate implementations which was my point....The design of TransactionLocal should take advantage of this and not be designed for the 0.00001% of cases.

Yes, but your argument applies to the delegate callouts, where I used the qualification
"or even"
The initialValue() callout is "user code".

I don't see how plain synchronization on the TransactionLocal (which is a global object
across all transactions) will ever be the correct thing to do. If you need to do that,
you probably shouldn't be using a TransactionLocal :-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879675#3879675

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879675

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: TransactionLocalDelegateImpl

[<dim...@jb...>]

"It could equally use the passed TransactionLocal rather than the implementation since there is a one-one correspondance."

But it would be no fun then, right? :)

quite impressive; I'd never guess this one.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879673#3879673

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879673

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: mt-issues with org.jboss.tm.TransactionLocal

[<ad...@jb...>]

"ad...@jb..." wrote : I'm also arguing that the external lock will probably be transaction scoped.

If the operation is already controlled by am equivalent or tighter lock,
anything inside TransactionLocal is redundant, even if it doesn't
suffer from the synchronize and callout anti-pattern I mentioned above.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879672#3879672

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879672

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: mt-issues with org.jboss.tm.TransactionLocal

[<ad...@jb...>]

I'm also arguing that the external lock will probably be transaction scoped.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879669#3879669

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879669

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: mt-issues with org.jboss.tm.TransactionLocal

[<bil...@jb...>]

"ad...@jb..." wrote : "bil...@jb..." wrote : 
  |   | Yes, we do control the delegate implementation.
  |   | 
  | 
  | No we don't. We allow any pluggable transaction manager to implement
  | TransactionLocalDelegate (with the TransactionLocalDelegateImpl if they don't).

I understand that, but we do control the implementation of 99.99999% of used TransactionLocalDelegate implementations which was my point....The design of TransactionLocal should take advantage of this and not be designed for the 0.00001% of cases.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879668#3879668

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879668

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: mt-issues with org.jboss.tm.TransactionLocal

[<ad...@jb...>]

The real issue here, is what are the implications of somebody doing
"get" twice in competing threads, or get/set - including set(null).

If there really is an issue of synchronization, it should be left to the
user of the TransactionLocal, who knows best what the scope is.

e.g. they might have code like the following which obviously needs an external
(reentrant) lock to be threadsafe:

  | TransactionLocal x = new TransactionLocal();
  | 
  | if (x.get() == someValue)
  |   x.set(anotherValue);
  | 

The caller will know best what the scope is.
i.e. I own this transaction for this critical section.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879666#3879666

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879666

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: mt-issues with org.jboss.tm.TransactionLocal

[<ad...@jb...>]

"bil...@jb..." wrote : 
  | Yes, we do control the delegate implementation.
  | 

No we don't. We allow any pluggable transaction manager to implement
TransactionLocalDelegate (with the TransactionLocalDelegateImpl if they don't).

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879663#3879663

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879663

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: TransactionLocalDelegateImpl

[<ad...@jb...>]

The difference is in the implementation details:

TransactionLocal

  |    protected void initDelegate()
  |    {
  |       if (transactionManager instanceof TransactionLocalDelegate)
  |          delegate = (TransactionLocalDelegate) transactionManager;
  |       else
  |          delegate = new TransactionLocalDelegateImpl(transactionManager);
  |    }
  | 

It could equally use the passed TransactionLocal rather than the implementation
since there is a one-one correspondance.

There is one object per transaction, 
see TransactionLocalSynchronization.valuesByLocal
with the synchronization being transaction scoped.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879662#3879662

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879662

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: mt-issues with org.jboss.tm.TransactionLocal

[<bil...@jb...>]

"ad...@jb..." wrote : 
  | In the case of ThreadLocal this is NOT TRUE since we do not control
  | initialValue() or even the "delegate" implementation.

Yes, we do control the delegate implementation.  WE MUST TAKE ADVANTAGE of controlling the delegate implementation.  We have one that is optimized for JBoss and one that will work in any transaction manager.  I do not want to introduce global synchronizations again.  I spent a 3-4 weeks finding and removing global synchronizations a few years ago, and I do not want myself or somebody else to have to do it again.  We should be limiting global synchronization whereever we can and TransactionLocal is definately a place we can do this.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879661#3879661

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879661

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: mt-issues with org.jboss.tm.TransactionLocal

[<bil...@jb...>]

A few years ago, I rewrote TransactionLocal to avoid Java synchronization.  Although not as bad as the global synchronization that was going on a few years ago, your changes reintroduce some level of global synchronization. 

I think the TransactionLocalDelegate implementation should be handling synchronization.  That way, our implementation can limit synchronization to only within threads in the same transaction.  This will cause most of the logic to move out of TransactionLocal into the delegate, but this is ok.


  | public class TransactionImpl {
  | 
  |      Object getTransactionLocalValue(TransactionLocal tlocal)
  |    {
  |      synchronized(transactionLocalMap) {
  |         if (transactionLocalMap.containsKey(local) { return transactionLocalMap.get(local);
  |         Object initial = local.initialValue();
  |         if (value == null) value = NULL_VALUE;
  |         transactionLocalMap.put(local, value);
  |         return value;
  |      }
  |    }
  | 
  |    void putTransactionLocalValue(TransactionLocal tlocal, Object value)
  |    {
  |        synchronized(tlocal) {
  |          ... 
  |       }
  |    }
  | 
  |    boolean containsTransactionLocal(TransactionLocal tlocal)
  |    {
  |       synchronized(tLocal) {
  |          ...
  |       }
  |    }
  | }
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879659#3879659

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879659

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: mt-issues with org.jboss.tm.TransactionLocal

[<ad...@jb...>]

Yes, this code needs making threadsafe, but not in the way you have done it.

This is exactly the type of code that leads to deadlocks:

  | public void doSomething()
  | {
  |    synchronized(this)
  |    {
  |       delegate.doSomething();
  |    }
  | }
  | 

Thread1 synchronized(somethingElse)
Thread2 ThreadLocal.doSomething() -> synchronized(ThreadLocal)
Thread1 ThreadLocal.doSomething() -> wait
Thread2 delegate.doSomething() -> synchronized(somethingElse)

DEADLOCK!!!!

You should never do

  | synchronized(something)
  | {
  |   somethingElse.call();
  | }
  | 

Unless something and somethingElse have been designed with a protocol
that orders their access.

In the case of ThreadLocal this is NOT TRUE since we do not control
initialValue() or even the "delegate" implementation.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879656#3879656

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879656

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - TransactionLocalDelegateImpl

[<dim...@jb...>]

A related question to my previous post, since I am there:

TransactionLocalDelegateImpl as an alternative implementation of TransactionLocalDelegate, when a TransactionManager other than TxManager is used, uses the 'this' value rather than the 'unused' TransactionLocal reference, in all calls to the delegate TransactionLocalSynchronization instance (as seen below).

This effectively means the HashMap in TransactionLocalSynchronization always stores a single object, no matter what TransactionLocal->Object association you want to make, within a transaction.

Is this intentional or just forgotten?

(the 'unused' name seems it's intentionall, but I don't understand why :)

Thanks


  |    public Object getValue(TransactionLocal unused, Transaction tx)
  |    {
  |       TransactionLocalSynchronization sync = getSynchronization(tx, false);
  |       if (sync == null)
  |          return null;
  |       return sync.getValue(this);
  |    }
  | 
  |    public void storeValue(TransactionLocal unused, Transaction tx, Object value)
  |    {
  |       TransactionLocalSynchronization sync = getSynchronization(tx, true);
  |       sync.setValue(this, value);
  |    }
  | 
  |    public boolean containsValue(TransactionLocal unused, Transaction tx)
  |    {
  |       TransactionLocalSynchronization sync = getSynchronization(tx, false);
  |       if (sync == null)
  |          return false;
  |       return sync.containsValue(this);
  |    }
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879655#3879655

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879655

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - mt-issues with org.jboss.tm.TransactionLocal

[<dim...@jb...>]

Although I started examining the TransactionLocal backends for thread-safety (i.e. TransactionLocalDelegateImpl + TransactionLocalSynchronization & TxManager + TransactionImpl), it seems to me that TransactionLocal itself needs to be more thread-safe because:

1) there is no other way to guarantee consistency between get()/set() independent from the delegate implementation. ( get() is an 1+1 step process: getValue() and potential storeValue(), set() a 2 step process: containsValue() and storeValue() )

2) no other way to guarantee initialValue() is executed exactly once.

I'm looking forward the following changes:

NOW

  | ...
  |    public Object get(Transaction transaction)
  |    {
  |       if (transaction == null) return initialValue();
  | 
  |       Object value = getValue(transaction);
  | 
  |       // is we didn't get a value initalize this object with initialValue()
  |       if(value == null)
  |       {
  |          // get the initial value
  |          value = initialValue();
  |          
  |          // if value is null replace it with the null value standin
  |          if(value == null)
  |          {
  |             value = NULL_VALUE;
  |          }
  | 
  |          // store the value
  |          storeValue(transaction, value);
  |       }
  | 
  |       // if the value is the null standin return null
  |       if(value == NULL_VALUE)
  |       {
  |          return null;
  |       }
  | 
  |       // finall return the value
  |       return value;
  |    }
  | ...
  |    public void set(Transaction transaction, Object value)
  |    {
  |       if (transaction == null) throw new IllegalStateException("there is no transaction");
  |       // If this transaction is unknown, register for synchroniztion callback,
  |       // and call initialValue to give subclasses a chance to do some 
  |       // initialization.
  |       if(!containsValue(transaction))
  |       {
  |          initialValue();
  |       }
  | 
  |       // if value is null replace it with the null value standin
  |       if(value == null)
  |       {
  |          value = NULL_VALUE;
  |       }
  | 
  |       // finally store the value
  |       storeValue(transaction, value);
  |    }
  | ...
  | 
CHANGES

  | ...
  |    public Object get(Transaction transaction)
  |    {
  |       // if a transaction is not yet associated with the thread,
  |       // return null to avoid calling initialValue() multiple times
  |       if (transaction == null)
  |       {
  |          return null;
  |       }
  |       // make the getValue() and potential storeValue()
  |       // atomic and avoid calling initialValue() twice
  |       synchronized (this)
  |       {
  |          Object value = getValue(transaction);
  |    
  |          // If we didn't get a value, get/set has not been called
  |          // so call initialValue() to give subclasses a chance to
  |          // do some initialization, and store the provided value
  |          if (value == null)
  |          {
  |             // get the initial value
  |             value = initialValue();
  |             
  |             // replace a null value with the NULL standin
  |             if (value == null)
  |             {
  |                value = NULL_VALUE;
  |             }
  |             // store the initial value
  |             storeValue(transaction, value);
  |          }
  |          // convert back the NULL standin to null, if needed
  |          if (value == NULL_VALUE)
  |          {
  |             value = null;
  |          }
  |          // return the stored value
  |          return value;
  |       }
  |    }...
  |    public void set(Transaction transaction, Object value)
  |    {
  |       if (transaction == null)
  |       {
  |          throw new IllegalStateException("there is no transaction");
  |       }
  |       // make the containsValue()/storeValue() atomic
  |       // and avoid calling initialValue() twice
  |       synchronized (this)
  |       {
  |          // If get/set has not been called, call initialValue() to
  |          // give subclasses a chance to do some initialization,
  |          // even if the initial value is not used.         
  |          if (!containsValue(transaction))
  |          {
  |             initialValue();
  |          }
  |          // replace a null value with the NULL standin
  |          if (value == null)
  |          {
  |             value = NULL_VALUE;
  |          }
  |          // finally store the value
  |          storeValue(transaction, value);
  |       }
  |    }
  | ...
  | 

Does it make sense? It will lock the TransactionLocal instance during the 2 operations, but I don't see how to avoid this. 

Another change I'm seeing, is that currently get(Tx) does:

  | ...
  |    public Object get(Transaction transaction)
  |    {
  |       if (transaction == null) return initialValue();
  | ...
  | 
when no tx is associated with the thread. But that means initialValue() can be executed many times, until the thread becomes associated with a tx.

Instead of throwing an exception (which is what set(tx) does), I imagine it is better to just return null, thus avoiding the multiple calls to initialValue(), and not break existing implementations.

Any views are welcome.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879654#3879654

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879654

[Jboss-dev-forums] [Design of JBoss Internal Benchmarking] - Re: AntBenchmarkReceiver question

[<cle...@jb...>]

I've already created org.jboss.jrunit.controller.persistence.DatabaseBenchmarkReceiver as a refactoring from AntBenchmarkReceiver.

The question now is if we should have AntBenchmarkReceiver also controlling FileBenchmarkReceiver by some kind of parameter. (Is there a usecase for that?).

I'm not seeing a usecase for this, but I want somebody else's opinion.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879652#3879652

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879652

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Admin Portal Refresh

[<roy...@jb...>]

Right. This isn't a problem with the portal, it is a problem with the default theme we ship with. If you plug-in the custom theme in the docs, you'll notice that when you minimize, "down arrow", a portlet, all it shows it the title bar and no content. 

The default theme insists on drawing a portlet window even when a portlet is minimized.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879640#3879640

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879640

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: disassociateThread on tm.suspend()

[<dim...@jb...>]

Thanks for the replies. I think the JTA spec is quite clear, too:

anonymous wrote : 
  | Suspend the transaction currently associated with the calling thread and return a Transaction object the represents the transaction context being suspended. If the calling thread is not associated with a transaction, the method returns a null object reference. When this method returns, the calling thread is associated with no transaction.
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879636#3879636

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879636

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Opening up ActionResponseImpl

[sgwood <nu...@jb...>]

That works!

Thanks, Julien



Sherman

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879634#3879634

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879634

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: An injection wiring scenario

[<ad...@jb...>]

The ability to override lifecycle methods is now supported.

e.g. rather than doing

  | <bean>
  |    <depends>SomeName</depends>
  | </bean>
  | 

You can now do

  | public void initialize(SomeBean bean)
  | {
  | // etc.
  | }
  | <bean>
  |    <create method="initialize">
  |          <parameter><inject bean="SomeName"></parameter>
  |    </create>
  | </bean>
  | 

Of course, other parameters such as plain values, collections, bean properties
are also supported.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879631#3879631

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879631

[Jboss-dev-forums] [Design of JBoss Internal Benchmarking] - AntBenchmarkReceiver question

[<cle...@jb...>]

This is a question addressed to Tom  Elrod which I think it would be nice t=
o have it recorded as a forum.

My plan for saving benchmarks is to use database persistence, being managed=
 by AntBenchmarkReceiver.

As you (Tom Elrod) created FileBenchmarkReceiver, maybe I should create a D=
atabaseBenchmarkReceiver and having AntBenchmarkReceiver dealing as a fa=C3=
=A7ade for both implementations. So, a question:

- Do you see a use case for having a DatabaseBenchmarReceiver outside AntBe=
nchmarkReceiver?
- Do you see an use case for AntBenchmarkReceiver also using FileBenchmarkR=
eceiver?


Clebert


View the original post : http://www.jboss.org/index.html?module=3Dbb&op=3Dv=
iewtopic&p=3D3879626#3879626

Reply to the post : http://www.jboss.org/index.html?module=3Dbb&op=3Dpostin=
g&mode=3Dreply&p=3D3879626

[Jboss-dev-forums] [Design of JBoss Portal] - Admin Portal Refresh

[erubinsky <nu...@jb...>]

Whenever I minimize a window in the the right-hand side of the admin portlet, the corresponding menu in the left-hand side is blank.

For example:
1) Log into the Portal as admin/admin.
2) Click on "admin" in the menu portlet on the left-hand side (LHS).
3) Click on "Edit existing role" under "Role Management."
4) Click on the "down arrow" to minimize the new window.

At this point the "Role Management" window in the LHS is now empty. 

My Vitals: 
JBoss [Zion] 4.0.2 (build: CVSTag=JBoss_4_0_2 date=200505022023)
Hibernate 3
Oracle 9i
Portal 2.0 RC2 (binary download on 5.31.05)



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879625#3879625

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879625

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Opening up ActionResponseImpl

[<ju...@jb...>]

I think that even GenericPortlet have an instance of JBossActionResponse passed as parameters.Could you try that ?



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879624#3879624

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879624

[Jboss-dev-forums] [Design of JBoss Internal Benchmarking] - Re: additions to JRunit

[<cle...@jb...>]

I don't have a JIRA task for this, but as part of my roadmap I'm creating a AtnBenchmarkReceiver taskdef which will serialize benchmark data to database.

Looking at build.xml from JRunit, take a look at run-SampleSimplePlainTest which has some usage.

This will of course be documented. It's just something I'm still working on.


Clebert Suconic

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879622#3879622

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879622

[Jboss-dev-forums] [Design of Security on JBoss] - Re: HostnameVerifier class issue.

[ignsdui <nu...@jb...>]

"sco...@jb..." wrote : This dependency was removed in the 4.0.0 final release. This starts up fine for me using the ibm 1.4.2 vm.

The problem we have is the following:
We want to use Jdeveloper 10.12 to deploy applications on a IBM P570 with AIX5.2 and Jboss 3.2.7 and the IBM JVM 1.4.
At this moment is is not possible to use Jboss 4 because the ADF Business components of Jdeveloper works only with a 3.2.x version of Jboss.
Is there a possibility in Jboss 3.2.7 to make it independent from Sun?
Is using IBM JVM 1.3 also a possible solution?
Or do we want to use an impossible combination of software components?

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879621#3879621

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879621

[Jboss-dev-forums] [Design of JBoss Portal] - Opening up ActionResponseImpl

[sgwood <nu...@jb...>]

After riding the JBoss portal learning curve (yes, Julien, I am still hanging in there!), I have successfully integrated JPivot (an OLAP UI) as a portlet. The only change I needed to JBoss Portal was to ActionResponseImpl, and I would like some feedback about whether this is a legitimate change that should be done to the base JBoss Portal code, or whether this should have been done another way.

I used the portlet bridge to get access to the HttpServletRequest and Response that the base JPivot code needed. Because of this, I had to have my JPivot portlet subclass GenericPortlet.

JPivot dynamically generates graphics (PNGs), PDFs and Excel files, sending a stream to the browser. Looking at the CMSPortlet, I saw the processAction method sending streams, ie.:

resp.sendBytes(contentType, content.getBytes());

This was not available to GenericPortlet subclasses which have an ActionResponse, not a JBossActionResponse, which implements sendBytes. The way I worked around this was to add a setResult(Result aResult) method to ActionResponseImpl and use it as follows:


  | PortletResponse portletResponse;
  | ByteArrayOutputStream baos = new ByteArrayOutputStream(16384);
  | 
  | ...
  | // Fill up baos
  | 
  | ActionResponseImpl responseImpl = (ActionResponseImpl) portletResponse;
  | org.jboss.portal.server.output.Result portletResult = new org.jboss.portal.server.output.StreamResult(windowCtx, contentType, baos.toByteArray());
  | responseImpl.setResult(portletResult);
  | 


Was there a better way to do this? This could be some other method I don't know about, or maybe implement sendBytes on ActionResponseImpl.

If not, can the ActionResponseImpl.setResult method be implemented in base JBoss Portal?


Thanks,


Sherman

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879616#3879616

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879616

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: disassociateThread on tm.suspend()

[<bil...@jb...>]

thread association/disassociation was for TransactionTimeouts.  I put this code in so that when  transaction timeout happened, it would  interrupt the thread.  I think dissociate should happen in suspend.  Otherwise you could interrupt a perfectly happy transaction/thread.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879613#3879613

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879613