Head in the Cloud

Microsoft SQL Server, as of version 9.0 (2005), allows you to cheat the max row size limit of 8K. If we have a row of variable length data types (ie. varchar), the total byte count can be more than 8K. SQL Server will magically spill the data over to the next page. Cool right? Well... yes and no. Cool if your hands are tied and it gets you out of a jam. Not cool if you care about database performance and scalability. Having a row span more than one page (in Oracle we call them blocks), results in page (or block) chaining. The overhead involved in block chaining can cause some significant performance hits depending on how often it happens, size of the table, fragmentation, etc. This goes for most any popular RDBMS. Let's look at Oracle (no point in just picking on SQL Server). Oracle allows a 64K max row size (and that's a hard limit... no loosy goosy there). However, block size is determined by the value of the db_block_size init parameter set during database cre

I was approached by a developer suggesting a reflection routine for taking values from a data transfer object and populating a business entity and vice versa. He argued that writing a TransferObjectAssembler for each DTO was too time consuming, and would be better suited with a reflection routine. My response was no, not a good practice. But why? It seemed clean enough. It was fairly straight forward code for the particular implementation scenario he was looking at. So, why not? It would certainly save a few million lines of code. But what are we really saving? And at what cost? It's no secret--reflection is slooooowwwww. At least in comparison to explicit design-time coding. Case in point: I helped out with a code review of a similar implementation where reflection was being used to create a generic routine to "convert" DTOs to business entities and vice-versa. While the DTOs were quite large, they were not ridiculously complex, and very typical of the particul

Error message "setProperty must be overridden by all subclasses of SOAPMessage". After reading this Jira issue, I followed the steps mentioned in "JBoss5.0.0GA Installation_And_Getting_Started_Guide.pdf - section 5.4 Java6 Note" and copy below jar files from the JBOSS_HOME/client directory to the JBOSS_HOME/lib/endorsed jbossws-native-saaj.jar jbossws-native-jaxrpc.jar jbossws-native-jaxws.jar jbossws-native-jaxws-ext.jar and thats it !! https://jira.jboss.org/jira/browse/JBWS-1439

I'll clean this up later, but in short: Download SrvAny.exe as part of the Windows server resource kit here: http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en Run: InstSrv.exe yourservicename "d:\pathtosrvany\svrany.exe" Edit the registry entry for the newly created service and add a "Parameters" key called "Application". Set the value to the full path of your executable.

Working with dates in Java (though not limited to Java) has always been a nightmare. There are lots of good articles out there in Google Land on the topic, but after some very good questions from my class, I thought I'd add my two-cents and code samples to the mix. Much of the confusion centered around conversion, so here's some basic how-to snippits: Convert java.util.Calendar to java.util.Date: java.util.Calendar calendar = java.util.Calendar.getInstance(); java.util.Date utilDate = calendar.getTime(); //or by using the constructor java.util.Date utilDate = new java.util.Date(calendar.getTimeInMillis()); Convert java.util.Date to java.sql.Date: java.util.Date utilDate = java.util.Calendar.getInstance().getTime(); java.sql.Date sqlDate = new java.sql.Date(utilDate.getTime()); Convert java.util.Calendar to java.sql.Date: java.util.Calendar calendar = java.util.Calendar.getInstance(); java.sql.Date utilDate = new java.sql.Date(calendar.getTimeInMillis()); Here we have to create

I recently ran into a concurrency issue with WCF on a customer's system. I'll get into the details later (though not too much detail... NDA ;) ), but it involved some testing of the various combinations of InstanceContextMode and ConcurrencyMode settings for a WCF service. The table below is an attempt to clarify the results... InstanceContextMode ConcurrencyMode Resulting Behaviour PerCall Single New InstanceContext created per call Calls processed concurrently, because each call gets it's own instance Multiple Same as with ConcurrencyMode.Single PerSession Single New InstanceContext is created for each client proxy connection Each call is pooled and processed serially in a FIFO manner Multiple New InstanceContext is created for each client proxy connection Each call is processed as soon as it arrives A single instance of the proxy is required for concurrent processing from a single client Singlton Single Single instance of an InstanceContext Each call is pooled and proc