Thread-Safe BC4J Application

Hello,
I have an BC4J-based application, based on BC4J9.0.2. I'm considering to upgrade my BC4J library to upper version to make my application more thread-safe.
How can I make thread-safe application using BC4J? Is there any specific Rule?
Thank you.

Hi,
Its hard to define a single rule since it depends upon how each application is using threads. I have included some thoughts about the most common scenarios for web clients below:
The BC4J client wizards (datatags, struts, JClient) will help you generate threadsafe applications. The general rule when writing a web client is to ensure that each "user", as represented by an HttpSession instance, has their own ApplicationModule instance. Using the ApplicationModule datatag or the BC4J/Struts framework will guarantee this.
Beyond this it may also be necessary to coordinate multiple concurrent requests from a single client (imagine a user pounding on the browser refresh button). One approach for solving this problem is to synchronize requests on some sort of session context. The ApplicationModule tag supports a latching mode (see the lock attribute) which performs this by synchronizing access to the SessionCookie (cached in session, used to acquire ApplicationModule instance). Support for latching will also be available in Struts in the 9.0.3.3 and later timeframe.
Hope this helps,

Similar Messages

BC4J View not Thread safe, user sessions are using the same view instance

Hi There,
We are using BC4J that came with JDeveloper 10.1.2.0.0 with Oracle 10G 10.1.2.0.0.
I have an BC4J account search view (BC4J AccountSearchView) that users can call to search for an account. So this view could be used by numerous users and pieces of code at the same time. Now my understanding is that each user gets their own instance of the view so changing the view's query should not be an issue (since the view definition is not changing). Under a light load the account search view looks like everyone get there own instance of the view and there expected account search results. But under a heavy user load when we have User A and User B the search query that was for User A will be used by User B. So the user results for one user will get the other users results.
I do not understand if the view definition is been changed by the other user and is impacting all view instances. How can this occur if it is thread safe?
I have enclosed the core code for this search.
If you can help that would be much appreciated, thanks in advance,
Nigel
accountSearchView.setQuery(baseSelectQuery+generateWhereClause());
logger.debug("SearchAccounts Query: "+accountSearchView.getQuery());
System.out.println("SearchAccounts SQL: "+accountSearchView.getQuery());
accountSearchView.setPassivationEnabled(false);
accountSearchView.setForwardOnly(true);
accountSearchView.executeQuery();
get attributes for each row result and place in new Java bean objects and return to user.

Nigel, we've only certified JDeveloper 10.1.2 against the Struts 1.1 with which it ships.
If there have been any changes in Struts 1.2 to the Struts Request Processor, then this could easily have an impact on the BC4JRequestProcessor's correct functioning, depending on what the changes were.
My quick look into the issue tells me that the ActionServlet init parameter named mapping in web.xml that we use for the 9.0.3-style BC4J/Struts integration is getting ignored by Struts 1.2. This parameter is used by Struts 1.1 to globally configure a custom ActionMapping subclass which can support additional properties. My quick test shows me that Struts 1.2 is ignoring this setting and so the oracle.jbo.html.struts11.BC4JActionMapping subclass of Struts's default ActionMapping is not getting used correctly as it does in Struts 1.1. This leads to errors when Struts tries to configure its actions in struts-config.xml since the Apache digester tries to set properties on the ActionMapping instance that don't exist (since the BC4JActionMapping has these properties, and it's not being used).
<servlet>
    <servlet-name>action</servlet-name>
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
    <init-param>
      <param-name>mapping</param-name>
      <param-value>oracle.jbo.html.struts11.BC4JActionMapping</param-value>
    </init-param>
</servlet>This is my quick analysis of what's not out-of-the-box compatible. I don't know enough about the changes in Struts 1.2 to know why this Struts 1.1 feature broke in Struts 1.2, or what the Struts 1.2 way to accomplish the same thing is.
I'd encourage you to use Worldwide Support's Metalink site and open a TAR for any time-critical issues you need assistance in resolving. Many of us are constantly traveling and only able to sporadically chime in with tips in the forum as our time permits.
The source of the BC4JRequestProcessor ships with the produce in the ./BC4J/src directory inside the bc4jstrutssrc.zip file.

How can I use a Selector in a thread safe way?

Hello,
I'm using a server socket with a java.nio.channels.Selector contemporarily by 3 different threads (this number may change in the future).
From the javadoc: Selectors are themselves safe for use by multiple concurrent threads; their key sets, however, are not.
Following this advise, I wrote code in this way:
         List keys = new LinkedList(); //private key list for each thread
         while (true) {
          keys.clear();
          synchronized(selector) {
              int num = selector.select();
              if (num == 0)
               continue;
              Set selectedKeys = selector.selectedKeys();
              //I expected this code to produce disjoint key sets on each thread...
              keys.addAll(selectedKeys);
              selectedKeys.clear();
          Iterator it = keys.iterator();
          while (it.hasNext()) {
              SelectionKey key = (SelectionKey) it.next();
              if ((key.readyOps() & SelectionKey.OP_ACCEPT) == SelectionKey.OP_ACCEPT) {
               Socket s = serverSocket.accept();
               SocketChannel sc = s.getChannel();
               sc.configureBlocking( false );
               sc.register( selector, SelectionKey.OP_READ );
              } else if ((key.readyOps() & SelectionKey.OP_READ) == SelectionKey.OP_READ) {
//.....Unfortunately synchronizing on the selector didn't have the effect I expected. When another thread select()s, it sees the same key list as the other thread that select()ed previously. When control arrives to serverSocket.accept(), one thread goes ahead and the other two catch an IllegalBlockingModeException.
I'm not willing to handle this exception, the right thing to do is giving disjoint key sets to each thread. How can I achieve this goal?
Thanks in advance

A single thread won't be enough cause after reading data from the socket I do some processing on it that may take long.So despatch that processing to a separate thread.
Most of this processing is I/O boundI/O bound on the socket? or something else? If it's I/O bound on the socket that's even more of a reason to use a single thread.
Anyway I think I'll use a single thread with the selector, put incoming data in a queue and let other 2 or 3 threads read from it.Precisely. Ditto outbound data.
Thanks for your replies. But I'm still curious: why is a selector thread safe if it can't be used with multiple threads because of it's semantics?It can, but there are synchronization issues to overcome (with Selector.wakeup()), and generally the cost of solving these is much higher than the cost of a single-threaded selector solution with worker threads for the application processing.

Is the Illustrator SDK thread-safe?

After searching this forum and the Illustrator SDK documentation, I can't find any references to a discussion about threading issues using the Illustrator C++ SDK. There is only a reference in some header files as to whether menu text is threaded, without any explanation.
I take this to mean that probably the Illustrator SDK is not "thread-safe" (i.e., it is not safe to make API calls from arbitrary threads; you should only call the API from the thread that calls into your plug-in). Does anyone know this to be the case, or not?
If it is the case, the normal way I'd write a plug-in to respond to requests from other applications for drawing services would be through a mutex-protected queue. In other words, when Illustrator calls the plug-in at application startup time, the plug-in could set up a mutually exclusive lock (a mutex), start a thread that could respond to requests from other applications, and request periodic idle processing time from the application. When such a request arrived from another application at an arbitrary time, the thread could respond by locking the queue, adding a request to the queue for drawing services in some format that the plug-in would define, and unlocking the queue. The next time the application called the plugin with an idle event, the queue could be locked, pulled from, and unlocked. Whatever request had been pulled could then be serviced with Illustrator API calls. Does anyone know whether that is a workable strategy for Illustrator?
I assume it probably is, because that seems to be the way the ScriptingSupport.aip plug-in works. I did a simple test with three instances of a Visual Basic generated EXE file. All three were able to make overlapping requests to Illustrator, and each request was worked upon in turn, with intermediate results from each request arriving in turn. This was a simple test to add some "Hello, World" text and export some jpegs,
repeatedly.
Any advice would be greatly appreciated!
Glenn Picher
Dirigo Multimedia, Inc.
[email protected]

Zac Lam wrote:
The Memory Suite does pull from a specific memory pool that is set based on the user-specified Memory settings in the Preferences. If you use standard OS calls, then you could end up allocating memory beyond the user-specified settings, whereas using the Memory Suite will help you stick to the Memory settings in the Preferences.
When you get back NULL when allocating memory, are you hitting the upper boundaries of your memory usage? Are you getting any error code returned from the function calls themselves?
I am not hitting the upper memory bounds - I have several customers that have 10's of Gb free.
There is no error return code from the ->NewPtr() call.
     PrMemoryPtr (*NewPtr)(csSDK_uint32 byteCount);
A NULL pointer is how you detect a problem.
Note that changing the size of the ->ReserveMemory() doesn't seem to make any difference as to whether you'll get a memory ptr or NULL back.
btw my NewPtr size is either
     W x H x sizeof(PrPixelFormat_YUVA4444_32f)
     W x H x sizeof(PrPixelFormat_YUVA4444_8u)
and happens concurrently on #cpu's threads (eg 16 to 32 instances at once is pretty common).
The more processing power that the nVidia card has seems to make it fall over faster.
eg I don't see it at all on a GTS 250 but do on a GTX 480, Quadro 4000 & 5000 and GTX 660
I think there is a threading issue and an issue with the Memory Suite's pool and how it interacts with the CUDA memory pool. - note that CUDA sets RESERVED (aka locked) memory which can easily cause a fragmenting problem if you're not using the OS memory handler.

Can use the same thread safe variable in the different processes?

Hello,
Can use the same thread safe variable in the different processes? my application has a log file used to record some event, the log file will be accessed by the different process, is there any synchronous method to access the log file with CVI ?
David

Limiting concurrent access to shared resources can be better obtained by using locks: once created, the lock can be get by one requester at a time by calling CmtGetLock, the other being blocked in the same call until the lock is free. If you do not want to lock a process you can use CmtTryToGtLock instead.
Don't forget to discard locks when you have finished using them or at program end.
Alternatively you can PostDeferredCall a unique function (executed in the main thread) to write the log passing the apprpriate data to it.
Proud to use LW/CVI from 3.1 on.
My contributions to the Developer Zone Community
If I have helped you, why not giving me a kudos?

Thread-safe alternative to XmlValue

Hi,
I'm using bdb xml in an application which visualizes 3d data stored in xml. When I load the data, it will be written into the db and I#m using XPath as query language. This works quite good, but as I'm using multiple threads within my application, I can't use XmlValues for referencing into the database, because they are not thread-safe. But I need to store at least some of those references to get quick access to some data, or to run a new query, based on a result node from an earlier query, later from another thread. Those referenced nodes will change during runtime, so indices won't help. So what can I do or did I miss something?
Thanks
Bjoern

Bjoern,
You may have to explain a bit more, especially the part about "referenced nodes will change during runtime." XmlValue objects that reference nodes are only guaranteed valid until the either (1) the XmlResults object containing them has been deleted or (2) the transaction in which they were retrieved ends. There are exceptions but those are the general rules.
The interfaces, XmlValue::getNodeHandle() and XmlContainer::getNode() exist to allow an application to store a string value that can be later resolved quickly back into an XmlValue. This works well unless the referenced node has been removed. It may be the answer you are looking for.
Regards,
George

Thread safe do-all class

Hi,
I'm new to Java programming and I've read through the forums and the numerous technical documents Sun has provided on how to make a GUI thread-safe. With what I've been able to understand, I created some template classes to handle the proper creation of JFrames, so I don't have to worry about playing with threads all the time. (I am operating under the assumption that invokeLater should handle the creation of all frames, not just the first window of the application).
Since I'm not completely confident I've grasped the point, I was wondering if someone could look at this code to see if I've got the right idea. Your help would be much appreciated.
Test.java
import frames.*;
public class Test
     public static void main(String args[])
          FrameOptions frameOpts = new FrameOptions("Options Window", 300, 400, true);
frames\FrameOptions.java
package frames;
public class FrameOptions extends FrameTemplate
     public FrameOptions(String title, int width, int height, final boolean visible)
          super(title, width, height);
          javax.swing.SwingUtilities.invokeLater     (     new Runnable()
                                             public void run()
                                                  createAndShow(visible);
     public void createAndShow(boolean visible)
          //Add all Swing components here.
          finishCreateAndShow(visible);
frames\FrameTemplate.java
package frames;
import java.awt.Dimension;
import javax.swing.JFrame;
public class FrameTemplate extends JFrame
     public FrameTemplate(String title)
          super(title);
     public FrameTemplate(String title, int width, int height)
          super(title);
          doSize(width, height);
     private void doSize(int width, int height)
          Dimension d = new Dimension(width, height);
          setMinimumSize(d);
          setPreferredSize(d);
     protected void finishCreateAndShow(boolean visible)
          pack();
          setVisible(visible);
}

OK, makes sense now.
For anyone else who may be new and wondering about this, this can be summed up as follows.
Summary 1:
If you create new frames from things such as menu events, you do not need to use invokeLater. Events are automatically done in the GUI thread/event dispatching thread. But if you're spawning these things from main() (or anything else not running in the EDT), you do.
If you're ever unsure of which thread a block of code is running in, just drop a System.out.println(javax.swing.SwingUtilities.isEventDispatchThread()); into it.
Summary 2:
Don't use those classes I wrote. They're rather pointless unless you're spawning all of your frames from main, which I suspect most people would not be doing.
Thanks for the clarification.
public static void main(String args[])
is run in a separate thread (separate from the GUi
i thread). So if you need to do painting or other
swing stuff from inside the main method, just use an
invoke later. If you create a new frame from the GUI
thread, you don't need to invoke later. Only if you
do it from the main method (or some other non-GUI
thread). Hope that helps

Thread Safe Pro*C++

I want to have pro*C++ object that is thread safe. In a method of the object, I give the
following code & get a pre-comipler error.
xsaLaOracle::connect()
/* declare the runtime context */
sql_context ctx;
/* enable threads */
EXEC SQL ENABLE THREADS;
/* allocate storage for the context */
EXEC SQL CONTEXT ALLOCATE :ctx;
/* other stuff happens here of course */
The pre-compiler error tells me that ctx in the ALLOCATE statement is undefined. I pretty much just took this code straight from chapter 11 (Multithreaded Applications)
of the Pro*C/C++ Precompiler Programmer's Guide. The examples in this chapter seem
to have bugs, so I'm not sure if I'm doing
something wrong, if the documentation is
wrong or both!! With my luck probably both!!
I am using Oracle & Pro*C/C++ 8.1.6 on
Solaris 7 platform.
If anyone has any ideas that would be great!
Joe Longo
null

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Joseph Longo ([email protected]):
I want to have pro*C++ object that is thread safe. In a method of the object, I give the
following code & get a pre-comipler error.
xsaLaOracle::connect()
/* declare the runtime context */
sql_context ctx;
/* enable threads */
EXEC SQL ENABLE THREADS;
/* allocate storage for the context */
EXEC SQL CONTEXT ALLOCATE :ctx;
/* other stuff happens here of course */
The pre-compiler error tells me that ctx in the ALLOCATE statement is undefined. I pretty much just took this code straight from chapter 11 (Multithreaded Applications)
of the Pro*C/C++ Precompiler Programmer's Guide. The examples in this chapter seem
to have bugs, so I'm not sure if I'm doing
something wrong, if the documentation is
wrong or both!! With my luck probably both!!
I am using Oracle & Pro*C/C++ 8.1.6 on
Solaris 7 platform.
If anyone has any ideas that would be great!
Joe Longo
<HR></BLOCKQUOTE>
Try this:
xsaLaOracle::connect()
/* declare the runtime context */
EXEC SQL BEGIN DECLARE SECTION;
sql_context ctx;
EXEC SQL END DECLARE SECTION;
/* enable threads */
EXEC SQL ENABLE THREADS;
/* allocate storage for the context */
EXEC SQL CONTEXT ALLOCATE :ctx;
/* other stuff happens here of course */
null

Thread Safe Issue with Servlet

I saw the following statement in one of the J2EE compliant server documentations:
"By default, servlets are not thread-safe. The methods in a single servlet instance are usually executed numerous times simultaneously (up to the available memory limit)."
I'm quite concerned with this statement for the primary reason that (I'm trying to reason by reading it out loud) servlets are not going to be thread-safe especially when available memory hit really really low!! So, when the application is still having sufficient memory, we will not likely run into concurrency problems, i.e the happy scenario for a short period after server is started. BUT, good things don't last long.. Anyway, hope someone can explain to me with more insights. Thanks.

Don't worry, memory occupation and thread safety are not related at all.
In my opinion, the following is the meaning of the statement you quote.
Since the servlet specification doesn't force any implementation to spawn a new servlet object upon each request (and this should be a real memory hit!), nor to synchronize calls to servlet methods, you should always code your servlet in a "stateless" fashion: you should be aware the same method on the same object could (and probably will) be called concurrently if multiple concurrent client requests are submitted.
Hope I've been clear enough...

What does it mean to be "thread safe"?

What does it mean to be "thread safe"?
I am working with a team on a project here at work. Someone here suggested that we build all of our screens during the initialization of the application to save time later. During the use of the application, the screens would then be made visible or invisible.
One of the objections to that idea was that the swing components (many of which we use) are not thread safe. Can anyone tell me what the relevance of that is?
Thanks

To understand why Swing is not thread safe you have to understand a little bit of history, and a little bit of how swing actually works. The history(short version) is that it is nearly impossible to make a GUI toolkit thread safe. X is thread safe(well, sorta) and it's a really big mess. So to keep things simple(and fast) Swing was developed with an event model. The swing components themselves are not thread safe, but if you always change them with an event on the event queue, you will never have a problem. Basically, there is a Thread always running with any GUI program. It's called the awt event handler. When ever an event happens, it goes on an event queue and the event handler picks them off one by one and tells the correct components about it. If you have code that you want to manipulate swing components, and you are not ON the awt thread(inside a listener trail) you must use this code.
SwingUtilities.invokeLater( new Runnable() {
public void run() {
// code to manipulate swing component here
});This method puts the defined runnable object on the event queue for the awt thread to deal with. This way changes to the components happen in order, in a thread safe way.

Coherence SimpleParser class is not thread safe?

Coherense has very convinent XML utility class, which we use it a lot within our Coherence related applications.
But we encounter some mysterious lock up (maybe deadlock?) issue and identified that it might be that the com.tangosol.run.xml.SimpleParser class is not thread safe.
We are using tomcat 6 and spring 2.0.6.
One of the webapp has 2 bean which implements InitializingBean interface.
Bean A's afterPropertiesSet() method will use com.tangosol.run.xml.XmlHelper.loadXml method to parse a XML file.
Bean B's afterPropertiesSet() method will acts as a tcp extend client and retrieve some data from a coherence cluster. Which I believe coherence will also use it's XML utility class when parsing the configuration files.
We encounter tomcat lockup (which never finish startup webapp deployment porcess) randomly like 1 out of 2 or 3 tries.
Use jconsole and connect to tomcat we can see that the main thread stuck in SimpleParser class. Here is the thread dump.
Name: main
State: RUNNABLE
Total blocked: 156 Total waited: 0
Stack trace:
com.tangosol.run.xml.SimpleParser.instantiateDocument(SimpleParser.java:150)
com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:115)
- locked com.tangosol.run.xml.SimpleParser@f10c77
com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:71)
com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:84)
com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:109)
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1201)
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1171)
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:425)
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251)
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:156)
- locked java.util.concurrent.ConcurrentHashMap@dee55c
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248)
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160)
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:287)
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352)
- locked java.lang.Object@d21555
org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:244)
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:187)
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49)
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3830)
org.apache.catalina.core.StandardContext.start(StandardContext.java:4337)
- locked org.apache.catalina.core.StandardContext@1c64ed8
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
- locked java.util.HashMap@76a6d9
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
- locked org.apache.catalina.core.StandardHost@1c42c4b
org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
- locked org.apache.catalina.core.StandardHost@1c42c4b
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
- locked org.apache.catalina.core.StandardEngine@37fd24
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
org.apache.catalina.core.StandardService.start(StandardService.java:516)
- locked org.apache.catalina.core.StandardEngine@37fd24
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
- locked [Lorg.apache.catalina.Service;@1cc55fb
org.apache.catalina.startup.Catalina.start(Catalina.java:566)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
After we add the depends-on tag to enforce bean B wait on bean A to finish initialization, we no longer encounter the lockup during tomcat startup.
We suspect that maybe SimpleParser class is not thread safe and will cause potential deadlock issue.
Edited by: user639604 on Jun 22, 2009 10:36 AM

While it doesn't show up as deadlock, I believe it probably is, as evidenced by these two threads:
"Timer-0" prio=10 tid=0xcb9a2800 nid=0x454b in Object.wait() [0xcb6e0000..0xcb6e10a0]
   java.lang.Thread.State: RUNNABLE
     at com.tangosol.run.xml.SimpleParser.instantiateDocument(SimpleParser.java:150)
    at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:115)
     - locked <0xf44e52f0> (a com.tangosol.run.xml.SimpleParser)
     at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:71)
     at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:99)
     at com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:129)
     at com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:95)
     at com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:72)
     at com.tangosol.util.ExternalizableHelper.<clinit>(ExternalizableHelper.java:4466)
     at com.evidentsoft.opcache.coherence.OPCacheCoherenceStorage.retrieve(OPCacheCoherenceStorage.java:341)
     at com.evidentsoft.opcache.coherence.OPCacheCoherenceStorage.retrieve(OPCacheCoherenceStorage.java:420)
     at com.evidentsoft.opcache.OPCacheManager.find(OPCacheManager.java:68)
     at com.evidentsoft.logserver.coherence.ClusterDetector.detectNewClusters(ClusterDetector.java:97)
     at com.evidentsoft.logserver.coherence.ClusterDetector.access$000(ClusterDetector.java:19)
     at com.evidentsoft.logserver.coherence.ClusterDetector$1.run(ClusterDetector.java:67)
     at java.util.TimerThread.mainLoop(Unknown Source)
     at java.util.TimerThread.run(Unknown Source)
"main" prio=10 tid=0x08059000 nid=0x4539 in Object.wait() [0xf7fd0000..0xf7fd11f8]
   java.lang.Thread.State: RUNNABLE
     at com.tangosol.run.xml.SimpleParser.instantiateDocument(SimpleParser.java:150)
     at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:115)
     - locked <0xf44ecd90> (a com.tangosol.run.xml.SimpleParser)
     at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:71)
     at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:84)
     at com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:109)
     at com.evidentsoft.coherence.util.ClusterConfigurator.generateConfigFile(ClusterConfigurator.java:319)
     at com.evidentsoft.coherence.util.ClusterConfiguratorProxy.afterPropertiesSet(ClusterConfiguratorProxy.java:51)
     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1201)
     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1171)
     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:425)
     at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251)
     at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:156)
     - locked <0xd65efb88> (a java.util.concurrent.ConcurrentHashMap)
     at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248)
     at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160)
     at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:287)
     at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352)
     - locked <0xd65efc28> (a java.lang.Object)
     at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:244)
     at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:187)
     at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49)
     at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3830)
     at org.apache.catalina.core.StandardContext.start(StandardContext.java:4337)
     - locked <0xd6092f60> (a org.apache.catalina.core.StandardContext)
     at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
     - locked <0xd54ff278> (a java.util.HashMap)
     at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
     at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
     at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
     at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
     at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
     at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
     at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
     at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
     at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
     - locked <0xd54ff1e8> (a org.apache.catalina.core.StandardHost)
     at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
     - locked <0xd54ff1e8> (a org.apache.catalina.core.StandardHost)
     at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
     - locked <0xd4fa60b8> (a org.apache.catalina.core.StandardEngine)
     at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
     at org.apache.catalina.core.StandardService.start(StandardService.java:516)
     - locked <0xd4fa60b8> (a org.apache.catalina.core.StandardEngine)
     at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
     - locked <0xd4f17ea0> (a [Lorg.apache.catalina.Service;)
     at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
     at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)The reason it isn't showing up as a deadlock in the thread dump is that the ExternalizableHelper static initializer isn't completing, so the other thread (blocking it) is waiting indefinitely on that class to become available.
Peace,
Cameron Purdy | Oracle Coherence

ODBC SQLGetData not thread-safe when retrieving lob

Hi MaxDB developpers,
we are in the process of migrating our solution from SapDb 7.4.03.32 to MaxDb 7.6.03.7. We use the ODBC driver on windows, from multi-threaded applications.
We encountered bugs in the ODBC driver 7.4.03.32 and made our own fixes since we had the sources. I checked if these problems were fixed in 7.6.03.7 and they are allmost addressed, but one:
when two threads use two different stmt from the same dbc and call simultaneously SQLGetData to retrieve a LONG column, a global variable not protected by a critical section is changed and the application crashes. The variable in cause is dbc_block_ptr->esqblk.sqlca.sqlrap->rasqlldp which is set by pa30bpcruntime and reset by pa30apcruntime during the call to apegetl. Calls to apegetl are protected by PA09ENTERASYNCFUNCTION except in SQLGetData, when it calls pa60MoveLongPos or pa60MoveLong.
Since MaxDB is a critical feature of our application, we would like to know when this bug can be fixed by SAP. Or maybe could we get access to the sources of sqlod32w.dll 7.6.03.7 to fix it ourselves ?
Thanks,
Guillaume

Hello Guillaume
Regarding the threaded access to SQLGetData. Of course, it is possible to manage the syncronization as you proposed. However, I'm still not sure, whether this really solves general problems.
The point is, that the MaxDB-ODBC driver is thread safe for concurrent connections, but not for concurrent statement processing within a single connection. Therefore I would like to ask you how your application accesses data via SQLGetData (due to connections and threads), and what amount of data is usually transfered.
Regards Thomas

Thread safe - what's that mean?

Hello,
I'm new to Java technology and I constantly read the Java forum as one way to learn from other's experience. What's that mean by "thread safe" as I often saw it in the forum and what's the difference between "thread" and "process"?
Thanks in advance.
wg97

I'm new to Java technology and I constantly read the
Java forum as one way to learn from other's
experience. What's that mean by "thread safe" as I
often saw it in the forum and what's the difference
between "thread" and "process"?I'll answer the second question first. The difference between thread and process depends on context. Generally in Java programming threads are well defined and processes are more general. A thread is a set of executing instructions in the VM that can execute "concurrently" with other sets of executing instructions. An appliction always contains at least one thread often called the 'main' thread. The main thread can spawn other threads so an application can have multiple concurrent sets of executing instructions. Thread-safe methods are those that enforce rules about how objects can access them i.e. they make sure that two threads are not performing actions on a single object at the same time that can result in errors. This is done in Java using the synchronized keyword.

Is singleton thread safe?

hello all,
please help me by answering these questions?
singleton patterns calls for creation of a single class that can be shared between classes. since one class has been created
Can singletons be used in a multithreaded environment? is singleton thread safe?
Are threading problems a consequence of the pattern or programming language?
thank you very much,
Hiru

Hi,
Before explaining whether a singleton is thread safe
e i want to explaing what is thread safe here
When multiple threads execute a single instance of a
program and therefore share memory, multiple threads
could possibly be attempting to read and write to the
same place in memory.If we have a multithreaded
program, we will have multiple threads processing the
same instance.What happens when Thread-A examines
instance variable x? Notice how Thread-B has just
incremented instance variable x. The problem here is
Thread-A has written to the instance variable x and
is not expecting that value to change unless Thread-A
explicitly does so. Unfortunately Thread-B is
thinking the same thing regarding itself; the only
problem is they share the same variable.
First method to make a program threadsafe-: Avoidance
To ensure we have our own unique variable instance
for each thread, we simply move the declaration of
the variable from within the class to within the
method using it. We have now changed our variable
from an instance variable to a local variable. The
difference is that, for each call to the method, a
new variable is created; therefore, each thread has
its own variable. Before, when the variable was an
instance variable, the variable was shared for all
threads processing that class instance. The following
thread-safe code has a subtle, yet important,
difference.
second defense:Partial synchronization
Thread synchronization is an important technique to
know, but not one you want to throw at a solution
unless required. Anytime you synchronize blocks of
code, you introduce bottlenecks into your system.
When you synchronize a code block, you tell the JVM
that only one thread may be within this synchronized
block of code at a given moment. If we run a
multithreaded application and a thread runs into a
synchronized code block being executed by another
thread, the second thread must wait until the first
thread exits that block.
It is important to accurately identify which code
block truly needs to be synchronized and to
synchronize as little as possible. In our example, we
assume that making our instance variable a local
variable is not an option.
Third Defence:--Whole synchronization
Here u should implement an interface which make the
whole class a thread safe on or synchronized
Thre views are made by Phillip Bridgham, M.S., is a
technologist for Comtech Integrated Systems.I'm
inspired by this and posting the same hereWas there a point in all of that? The posted Singleton is thread-safe. Furthermore, some of that was misleading. A local variable is only duplicated if the method is synchronized, a premise I did not see established. Also, it is misleading to say that only one Thread can be in a synchronized block of code at any time because the same block may be using different monitors at runtime, in which case two threads could be in the same block of code at the same time.
private Object lock;
public void doSomething() {
    lock = new Object();
    synchronized(lock) {
        // Do something.
}It is not guaranteed that only one Thread can enter that synchronized block because every Thread that calls doSomething() will end up synchronizing on another monitor.
This is a trivial example and obviously something no competent developer would do, but it illustrates that the statement assumes premises that I have not seen established. It would be more accurate to say that only one Thread can enter a synchronized block so long as it uses the same monitor.
It's also not noted in the discussion of local variables vs instance variables that what he says only applies to primitives. When it comes to actual Objects, just because the variable holding the reference is unique to each Thread does not make use of it thread-safe if it points to an Object to which references are held elsewhere.

Thread Safe Testing

I havn't written much mult-threaded code but I realise it's important when many web round-trips are required.
How do I design, test and verify that I have a thread-safe application? I don't like relying on the testing statistics of chance unless the odds of failure are 0.0001%!
Is there a correct way to verify a thread-safe application?

I agree it is a lofty, though sadly in all probability too time consuming, goal to achieve. However, there are a few pitfalls to watch out for that should get most of the common, pernicious thread safety issues:
Synchronize data that must be shared. This will involved performance bottle-necks. If the data is read-mostly, consider a Singleton cache. Though pitfalls will always remain here. Data sharing among threads, IMO, is the single greatest issue.
Use static methods and instances wisely. If an object has instance variables that are used from method to method call (either within the class or from the caller), then state exists for that object. It is inherently a candidate to look at in terms of thead-safety. This class should be created for each logical unit of work that depends on its state. So, do not reuse these classes among threads (or at least provide an init() or reset() method to clear the state). The same applies to static methods. You can safely use a static method from multiple threads if it does not modify other static variables (e.g., changing the state of a static variable).
Within the Collections API, pay attention to which types are synchronized and which are not. The Javadocs will specify.
Try to write methods thread-safe. Have them only use the arguments provided in the method's signature.
Watch for relatively simple race conditions that can easily be spotted.
static private Singleton INSTANCE;
private Singleton() {
    super();
    // Now I will fetch values from a database, perhaps taking seconds
static final public Singleton getInstance() {
      if (INSTANCE == null) {
         INSTANCE = new Singleton(); // what if this takes some time, e.g. database query to get cache values?
      return INSTANCE;
}Not good. Here's a possible refactoring:
private static final Singleton INSTANCE; // bonus, we can now make it final
static {
   INSTANCE = new SIngleton(); // Occurs only when class is loaded, atomic
public static final Singleton getInstance() {
return INSTANCE; // no race condition
}The above would be even more applicable and pronounced if you offered a static refresh() method on the instance, say to refresh its cache of data from a database.
Seems easy, right? The rub is that you need to verify that a given method does not call other methods that are not thread-safe. If every class you design follows the above precepts, then you will probably only be chasing down rarer thread-safety issues.
- Saish

Thread-Safe BC4J Application

Similar Messages

Maybe you are looking for