When do you need to explicity specify initial context factory?

public class WsnInitialContextFactory
extends java.lang.Object
implements javax.naming.spi.InitialContextFactory

This class is the initial JNDI context factory for WebSphere Application Server. To use this class as the initial context factory for initial JNDI contexts, set the property java.naming.factory.initial to a value of com.ibm.websphere.naming.WsnInitialContextFactory. JNDI clients running in the WebSphere runtime environment should not have to set this property because it is already set in a copy of jndi.properties contained in a WebSphere runtime jar file. To set this property from a program, you can use the Java constant, javax.naming.Context.INITIAL_CONTEXT_FACTORY, for the property name, and the constant, com.ibm.websphere.naming.PROPS.INITIAL_CONTEXT_FACTORY, for the property value.

This class is only a facade of sorts and does not contain any real implementation. It delegates to an instance of the class specified by an internal property set in the properties file, jndiprovider.properties, which is part of the WebSphere installation. Users of WebSphere do not need to set this property. However, they do need jndiprovider.properties to be in their runtime environment so that it can be found by the class loader in effect.

XA vs non XA transactions.

Here is a good write up from server side.com

http://www.theserverside.com/discussions/thread.tss?thread_id=21385

XA and NonXA datasource
Posted by: Mike Spille on Thu Sep 11 17:28:55 EDT 2003 in response to Message #95297
An XA transaction, in the most general terms, is a "global transaction" that may span multiple resources. A non-XA transaction always involves just one resource.

An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).

XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form.

Most stuff in the world is non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database. XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources. Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are commited across all of the resources. When you say "rollback", _everything_ is rolled back across all resources.

The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources.

In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can't participate in a global transaction (sort of - some people implement what's called a "last participant" optimization that can let you do this for exactly one non-XA item).

For more details - see the JTA pages on java.sun.com. Look at the XAResource and Xid interfaces in JTA. See the X/Open XA Distributed Transaction specification. Do a google source on "Java JTA XA transaction".

-Mike

Good technology blog to read on a daily basis to get myself updated on latest trends in software development.

http://www.labnol.org/internet/most-useful-web-applications/6278/

Tool to create screen shots of all actions on a PC.

There is a tool that can record all your actions on your PC and play it for you.

Here is the link for it:

http://www.jingproject.com/

It does more than Snag It or any other tool I used.

JMS: How to purge queues.

This is an example from below:
http://www.amazon.com/Enterprise-Integration-Patterns-Designing-Addison-Wesley/dp/0321200683/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1195232579&sr=8-1

This book contains many examples and patterns which are wonderfully handy in messaging.

import javax.jms.JMSException;
import javax.jms.MessageConsumer;
import javax.jms.Queue;
public class ChannelPurger extends JmsEndpoint
{
public static void main(String[] args)
{
if (args.length != 1) {
System.out.println("Usage: java ChannelPurger ");
System.exit(1);
}String queueName = new String(args[0]);
System.out.println("Purging queue " + queueName);
ChannelPurger purger = new ChannelPurger();
purger.purgeQueue(queueName);
}
private void purgeQueue(String queueName)
{
try {
initialize();
connection.start();
Queue queue = (Queue) JndiUtil.getDestination(queueName);
MessageConsumer consumer = session.createConsumer(queue);
while (consumer.receiveNoWait() != null)
System.out.print(".");
connection.stop();
} catch (Exception e) {
System.out.println("Exception occurred: " + e.toString());
} finally {
if (connection != null) {
try {
connection.close();
} catch (JMSException e) {
// ignore
}
}
}
}
}