PostgreSQL performing huge updates [1106]

PostgreSQL is a pretty powerful database server and will work with almost any settings thrown at it. It is really good at making do with what it has and performing as it is asked.

We recently found this as we were trying to update every row in a table that had over eight million entries. We found in the first few tries that the update was taking over 24 hours to complete which was far too long for an update script.

Our investigation of this led us to the pgsql_tmp folder and the work_mem configuration parameter.

Continue reading

Using CXF Interceptors to do some magic around your web service calls [1105]

We use JBossWS CXF for a heavily utilised enterprise system. It links into spring to pick up and execute beans. We have a bunch of exceptions that could get thrown.

To simplify it, the code was originally written to create an anonymous class a la Runnable which is wrapped around a try catch block. The exceptions that are thrown are then converted to a soap fault and passed back.

	private SOAPFaultException convertToSoapException(ApplicationException e)
	{
		try {
			if(null == soapFactory) {
				soapFactory = SOAPFactory.newInstance();
			}
			SOAPFault sf = soapFactory.createFault();
			sf.setFaultString( e.getMessage() );
			sf.setFaultCode( Integer.toString(e.getErrorCode()) );
			return new SOAPFaultException( sf );
		} catch(SOAPException soapException) {
			throw new RuntimeException( soapException );
		}
	}

Nothing inherently wrong with this. However, there are a couple of issues with this in that each soap method is set to throw an ApplicationException and there is not further documentation of which of the subclasses are actually relevant to that method.

In a runtime environment, this is not hugely relevant. However, when generating documentation from the WSDL’s, it is.

To resolve this, we changed each method to throw their relevant exception, and wrote an interceptor to pick up the exception and convert it…

Continue reading