@threadsafety

What do you guys think about having a standard way to document thread safety of a class and its methods? Javadoc tool would place all the thread safety information in a standard place, and if there was no @threadsafety tag then it would default to something like "This class and its methods are thread safe". That way a lot of guess work in figuring out if something is thread safe would go away.

There's a request for this at:
Javadoc needs a standard thread safety tag
http://developer.java.sun.com/developer/bugParade/bugs/4725927.html
As one of our architects says:
Merely making the tag available wouldn't do too much. If we could "lead
by example," documenting the thread safety of each of our classes with the
tag, that would be another story. But that's quite an effort.
We are unlikely to use it in the J2SE anytime soon, but it would be useful
for other APIs.
I have added it to the list of proposed tags at:
-Doug

Similar Messages

ServiceLocator - InitialContext - ThreadSafety

Hi,
on otn I found an implementation of the ServiceLocator pattern:
http://otn.oracle.com/sample_code/tech/java/ejb_corba/vsm/files/src/oracle/otnsamples/util/ServiceLocator.java.html
It uses an InitialContext shared by all Threads.
In the Javadoc of InitialContext I found the following:
"An InitialContext instance is not synchronized against concurrent access by multiple threads. Multiple threads each manipulating a different InitialContext instance need not synchronize. Threads that need to access a single InitialContext instance concurrently should synchronize amongst themselves and provide the necessary locking."
Do I have to expect problems when I use this ServiceLocator implementation?
Thanks for your comments
Guenther

Guenther,
In that sample they have assumed that InitialContext configuration wont change at any time.
So i dont think there is a need for synchronization..(in their implementation)
In your application, if each thread adds/modifies their InitialContext configuration, then synchronization has to be taken care...
One more thing regarding caching of InitialContext is that, if the InitialContext gets modified(by add/modify JNDI entries- using hot deployment or somthing) at runtime, then you will have to refresh InitialContext often....so you cant cache them...
Correct me if i am wrong...
Cheers
--Venky
Hi,
on otn I found an implementation of the ServiceLocator pattern:
http://otn.oracle.com/sample_code/tech/java/ejb_corba/vsm/files/src/oracle/otnsamples/util/ServiceLocator.java.html
It uses an InitialContext shared by all Threads.
In the Javadoc of InitialContext I found the following:
"An InitialContext instance is not synchronized against concurrent access by multiple threads. Multiple threads each manipulating a different InitialContext instance need not synchronize. Threads that need to access a single InitialContext instance concurrently should synchronize amongst themselves and provide the necessary locking."
Do I have to expect problems when I use this ServiceLocator implementation?
Thanks for your comments
Guenther

ORA-21779: duration not active

Guys, it looks like nobody knows much about this error and Oracle support is no help.
The problem seem to be machine/environment specific.
We get this exception consistently on some of the oracle/intermedia queries on two out of six identical environments. The queries are run from a servlet, only number and varchar2 fields used, no LOBs.
The configuration across all the environments:
WL 8.1
Oracle 9.2.0.7.0
Oracle JDBC 9.2.0.5
Some online sources mention that the ORA-21779 error is fixed by some Oracle patch sets, but we've done a cumulative update a couple of weeks ago, maybe someone knows a specific patch or the reason for the problem?
Thanks,
Vitaly

chernovtsy wrote:
Here's the relevant part of the trace, thanks!
java.sql.SQLException: ORA-21779: duration not active
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:582)
at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1986)
at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java:1253)
at oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:295)
at com.skila.search.AsynSearchProcessor.getRecordPriority(AsynSearchProcessor.java:747)
at com.skila.search.AsynSearchProcessor.iteratorResulSet(AsynSearchProcessor.java:790)
at com.skila.search.AsynSearchProcessor.fetchByDate(AsynSearchProcessor.java:311)
at com.skila.search.AsynSearchProcessor.getSearchResults(AsynSearchProcessor.java:1069)
at com.skila.search.SearchServlet.doPost(SearchServlet.java:293)
at com.skila.reddog.common.AbstractSkilaServlet.processRequest(AbstractSkilaServlet.java:182)
at com.skila.reddog.common.AbstractSkilaServlet.service(AbstractSkilaServlet.java:160)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)That looks like an ancient version of the driver... Ca you try repeating this with the
latest 10g (10.2) driver? How easily/regularly can you repeat this? Is there anything
fancy about your JDBC code? Can I see it? One main problem people have with
JDBC in servlets is not making all JDBC objects method-level objects, and therefore
risking non-threadsafety.
Regardless, have you shown Oracle support a full JDBC stacktrace of the exception?
thanks
Joe
PS: is there any WebLogic code in the picture? It seems you're making
direct JDBC connections...
Joe

Limited connections to OPA

I've been asked to look at a live problem we have where we seem to have a bottleneck calling OPA. The high level design is the client is running as a WCF service and as it chunks up the work it needs to do it spawns new threads which in turn call OPA running on a separate box running under IIS. The call is through the standard .net OPA API.
Looking at the logs the threading seems to be working and when it is under load you can see it spawning plenty of threads which are calling OPA. However if you watch the open connections on the OPA server these never rise above 8 per cpu.
Initial thoughts are the problem is,
• Our calling code is broken i.e. the way our code breaks a chunk of work into parallel threads (this seems to be behaving although I'm not sure we've over complicated matters)
• The wrapper we’ve written that utilises the OPA API (seems to follow standard pattern so low possibility)
• The OPA API provided is limiting in some way. Potentially tied to how it maintains its own threadsafety in a singleton.
• The set up of IIS hosting OPA (the connections created are so low I think this is a low possibility)
• What we are seeing is a red herring and I need to go and read about how IIS opens and manages connections
• Somethings a miss on the network between the 2 boxes
Am I missing anything obvious from the OPA side?
Thanks in advance,
Paul Fitz.

From my experience this is very likely to be the IIS setup on the OPA box.
Setting up IIS to run OPA fast is a bit of an art form and far beyond what I can write in these pages! Assuming you are using ODS (not OWD as this requires a different setup as it's stateful) Initially check
1. You have a separate App Pool for OPA
2. If you are using IIS 7.5 you are running in integrated pipeline mode
3. Set the app pool for minimum monitoring, small timeouts etc. ODS simply doesn't need stuff like 'Load User Profile' and all the normal website type stuff as it's stateless
When you've got that setup correctly then look at your WCF configuration - in particular the web (or app) .config file and make sure that you have a connection management tag under system.net. You can then override the default connection behaviour. This is the configuration FROM your WCF TO the OPA server - effectively your WCF is acting as a client of OPA in this instance, so the connection behaviour needs to be from the caller and not on the callee.
It may alos be that you have to make alterations to your machine.config file on either client or server
See http://support.microsoft.com/kb/821268 for more details - I know it's about ASP.NET but its a good gateway in....
Roger

@threadsafety

Similar Messages

Maybe you are looking for