To all future Devs who may stumble across this post, this is how I fixed the issue...
In Spring LDAP 1.3.2, SingleContextSource does not have a constructor that takes a ContextSource, but rather only one that takes a DirContext. I didn't see any means to get a single DirContext
from my LdapContextSource, so I was unable to use the suggestion of ig0774.
However, having read the Oracle documentation, I found that it has built-in since 1.4.1 a VERY simple pooling mechanism. Further reading in the Spring API docs for LdapContextSource
showed that it has the ability to turn this pooling mechanism on through a call to setPooled(boolean). This basically makes it so that the call to close()
on the connections doesn't not really close the connection, but rather returns it to the "pool". Since my application is one big linear thread, and only one "connection" is opened at a given time, this has the net effect of causing it to simply use the same connection, thus bypassing the issue I was seeing were my updates were working faster than the replication. After turning on the built-in pooling, my errors have seemingly stopped.
Note that this is NOT a good means to implement a pooling scheme for LDAP. As the JavaDoc says, this built-in pooling mechanism has many flaws. If you need pooling, then you are MUCH better off using Spring LDAP's PoolingContextSource. In my case, however, I wanted the opposite of a "pool", so things seemed to work out for me in that regard.
The other option would have been to simply not use the VIP but rather connect directly to a single Active Directory server, but then I loose fail-over ability.