SQL Server connection only partially encrypting

Question

Hi all,
We have a Java servlet running on Tomcat and Windows and all database connections are encrypted using SSL. This works apart from a strange issue on one of the connections (SQL Server) which I do not understand. I am using WireShark to check the encryption is
working but, whenever a new login is performed through the servlet, the FIRST data transfer for this particular connection is only partially encrypting, but if a second or third data transfer to this database connection is made under the same login the entire
message is encrypted.
After the login all requests are handled through a token provided by Tomcat. The servlet also connects to an Oracle database which encrypts all the messages from the outset.
Why will the first data transfer only be partially encrypting?  There is no SQL Server client on the client\calling machine.
Here is the JNDI entry in Tomcats context.xml file but obviously a few things amended to hide them
<resource auth="Container"></resource>
driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDriver"
factory="org.moss.jdj.dbcp.EncryptedDataSourceFactory" maxActive="100"
maxIdle="30" maxWait="10000" name="jdbc/connectionname"
password="*******" type="javax.sql.DataSource"
url="jdbc:sqlserver://databaseinstallname\db_instancename:2369;
databaseName=Images;encrypt=true;trustServerCertificate=true"
username="*******" />
Here is the entry in Tomcats server.xml file but again a few things amended to hide them
<connector port="8443"></connector>
protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true"
maxThreads="150" minSpareThreads="25"
enableLookups="true" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" KeyAlias="ows"
KeystoreFile="C:\SSLKeys\ows.key" KeystorePass="********" />
Here is the section of the message viewed in Wireshark with the meta-data the rest of the message is encrypted.  I have changed the company name with "companyname" or my manager would not be happy
d....companyname1.0..
..&...,d....corp1"0 ..U....companyname Issuing CA 20..
140818140356Z.
150818140356Z0+1)0'..U... EDMSSQL.corp.companyname.co.uk0..0
..*.H..
.........0.........-........I.4.u![z.Dw..N.?...5..
..O*k8a..k....%.c.....#.........G.>....,>.O..0.[.....*i....g./......%..
..j[.z....._.....B.{[.........0...0...+.....7.......M.a.c.h.i.n.e0...U.%..0...+.........+.......0...U........0...U..........{.Wc5
z..q...t.u0...U.#..0...m.&<......]q:F..&S.q0..G..U.....>0..:0..6...2.....Khttp://pki.corp.companyname.co.uk/pki/companyname%20Issuing%20CA%202.crl...ldap:///CN=companyname%20Issuing%20CA%202,CN=HQISSUINGCA2,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=corp,DC=companyname,DC=co,DC=uk?certificateRevocationList?base?objectClass=cRLDistributionPoint0....+..........0..0....+.....0....ldap:///CN=companyname%20Issuing%20CA%202,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=corp,DC=companyname,DC=co,DC=uk?cACertificate?base?objectClass=certificationAuthority\0+..U...$0".
EDMSSQL.corp.companyname.co.uk0
..*.H..
............E=....&..L:...G....'h....F...~...'..T...C..xD...R.a.!~..I..%2l.......84\.]...U..`A1..0...s...........2..].:J./.Tg.v...:t...3...\.........*..
.x2....z......QV.$
..=...e.QfE.....B.`.tE..........a.~..t?..F.]a.~.5>.Eg...I..[X...5.X....6.*M
.......;..f...5......0...0.........
..........0
..*.H..
.....041200..U...)companyname Root Certification Authority0..
131021101249Z.
181021102249Z0..1.0..
..&...,d....uk1.0..
..&...,d....co1.0..
..&...,d....companyname1.0..
..&...,d....corp1"0 ..U....companyname Issuing CA 20.."0
..*.H..
..........0..
........Z..v..S.d..8..\...e....T)...u.....n..j.......(...U....y0z..2J..hC.<. ...Q...2...Z.QE...C.!..SL.m..Q....b..&..oG<<a href="mailto:?&%........c...dV..J..q./x@..~..%[email protected]~s.....>...8...........p.s.)f.*i.+.>.{....+j.f..j..E...]C.74L......7........d0..`0...+.....7.......0...U......m.&<......]q:F..&S.q0...+.....7">?&%........c...dV..J..q./x@..~..%[email protected]~s.....>...8...........p.s.)f.*i.+.>.{....+j.f..j..E...]C.74L......7........d0..`0...+.....7.......0...U......m.&<......]q:F..&S.q0...+.....7.....
.S.u.b.C.A0...U........0...U.......0....0...U.#..0...OVqG..U%.....`.;..~.0..d..U.....[0..W0..S...O...K.[http://pki.corp.companyname.co.uk/pki/companyname%20Root%20Certification%20Authority.crl...ldap:///CN=companyname%20Root%20Certification%20Authority,CN=hqrootca1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=corp,DC=companyname,DC=co,DC=uk?certificateRevocationList?base?objectClass=cRLDistributionPoint0..i..+..........[0..W0q..+.....0..ehttp://pki.corp.companyname.co.uk/pki/hqrootca1_companyname%20Root%20Certification%20Authority.crt0....+.....0....ldap:///CN=companyname%20Root%20Certification%20Authority,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=corp,DC=companyname,DC=co,DC=uk?cACertificate?base?objectClass=certificationAuthority0
..*.H..
Thanks in advance
Regards
AJF</connector><//connector></resource><//resource>

Answer 1

Thanks for response.  I have edited the question to include the section of message with the meta-data that is not being encrypted.
There are no errors and the web request is providing the correct information in the web response when viewed in SoapUI.  I have run checks and examined the tomcat logs and there are no errors at all.
Thank you
Regards
AJF