<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Java on Benny Simmonds</title>
    <link>https://www.bencode.io/categories/java/</link>
    <description>Recent content in Java on Benny Simmonds</description>
    <generator>Hugo -- 0.149.1</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 12 Jan 2016 21:12:10 +0000</lastBuildDate>
    <atom:link href="https://www.bencode.io/categories/java/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Java Prepared Statement Overflow</title>
      <link>https://www.bencode.io/posts/2016-01-12-jdbc-overflow/</link>
      <pubDate>Tue, 12 Jan 2016 21:12:10 +0000</pubDate>
      <guid>https://www.bencode.io/posts/2016-01-12-jdbc-overflow/</guid>
      <description>&lt;p&gt;On the hunt for an sporadic &lt;code&gt;DB2 SQL Error -805&lt;/code&gt;, I took a dive into some logs. It had been rearing its ugly head for weeks now, and starting to impact our business area. The call stack pointed straight to the bad patch of code, the Java EE solution contains a programmatic &lt;code&gt;TimerService&lt;/code&gt;, responsible for shuffling data from one database to other; a rudimentary replication solution in other words. The specific source database in this case happened to be DB2 running on AIX. No big deal. Except that the code has proven to be flakey under load. That is, the code was transferring ~500,000 records daily, but was choking for ~100,000 records, the lions share of the load and failures seemed to pertain to BLOB data.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Java EE Container Context Roots</title>
      <link>https://www.bencode.io/posts/2015-05-23-context-roots/</link>
      <pubDate>Sat, 23 May 2015 16:18:19 +0000</pubDate>
      <guid>https://www.bencode.io/posts/2015-05-23-context-roots/</guid>
      <description>&lt;p&gt;Occassionally the need to do multiple side-by-side deployments of the same packaged application can arise. In a scenario recently faced, it was useful to have multiple versions of our packaged EAR deployed and configured slightly differently (for example: with and without security in QA environments). As the application is expected to run hot 24/7, the need for a simple side-by-side versioning (e.g. v1, v2) scheme was also important. Allowing us to deploy &lt;code&gt;v1&lt;/code&gt;, and later breaking (incompatible) versions &lt;code&gt;v2&lt;/code&gt;, &lt;code&gt;v3&lt;/code&gt;, given our service consumers the freedom to upgrade when convenient.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
