Independent Reach
	Home	Products	Services	Technology	FAQs	Contact

Technology

• Tools
  • In the development of Tromis, we used Java, Eclipse, iText, MySQL and Tomcat. It's hard not to be amazed at the quality of these products. Being a former Windows developer, I find it hard to stop using my Windows workstation. That's OK, these products are all free, fast, reliable and simple to install, even on Windows!
  
  
• Exceptions
  • Since 2001, we have standardized on an exception handling approach which pays off every day, so we think it's worth sharing.
    • about 5% of exceptions can be ignored, so they get caught and swallowed and logged
    • about 0.01% of exceptions are correctable and forseeable, so they get caught and handled
    • the remaining 94.99% of exceptions are unexpected and therefore probably not safely handled, so we throw them. At the highest level possible, we catch all exceptions, report them, with stack trace information, and request and session information if applicable, via email to the supporting developer. The user is informed that an unexpected error has occurred, and they will be contacted by the system administrator when a remedy is deployed. Several of the last few times we got an emailed exception report, we made the correction and had it ready for the next deployment before the user realized he/she had encountered a bug!
    • the rationale is not to try to anticipate and/or handle all exceptions - it is to let the user know something that wasn't their fault went wrong, then to die gracefully and notify someone who can fix the problem with the information needed to do so.
    
    
  • Persistence
    • Many persistence frameworks are available. We chose to use our own, and we believe the excellent performance and maintainability of Tromis is largely attributable to this decision. We used our own framework for the following reasons:
      • We had what we felt was a mature persistence framework suitable to our development practices written in C#, which was a port of an older one written in C++
      • Reflection, metadata and interface implementation can be used with type safety; configuration files less so
      • We prefer public fields to getters and setters for simple data value objects
      • We felt the largest jdbc performance gain to be had without caching objects is to cache prepared statements, but found no framework whose docs clearly stated it used that technique.
      • We found no framework whose docs clearly stated it leveraged the rich capabilities of Database and ResultSet meta data.
      Techniques employed:
      • all SQL statements get prepared and cached with their connection, which in turn get pooled for performance
      • busiest connections are taken from the pool first, because they have the most cached statements
      • SQL for select/insert/update/delete/exists of single records is generated at run time using database meta data and reflection
      • SQL text is cached for performance
      • database meta data is cached for performance
      • reflection type information is cached for performance
      • data value objects are NOT cached, to avoid complexity and ease eventual horizontal scaling
      • methods are provided to the higher tiers so that controls can be sized and input can be trimmed to match the column they are destined for
      • SQL is the only query language