Moving to Horde Base since it affects any code using Null sessions.

ActiveSync uses the Null session driver since it only needs a session 
long enough to ensure there is a session_id (some of the auth drivers 
need one for crypo functionality). I added code to immediately call 
session_write_close() after the session is created to avoid any 
locking issues.

Changes have been made in Git (master):

commit 645494515230ddfd89b435c711e480e7b0468a0c
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Mon Dec 3 14:37:44 2012 -0500

     Immediately close the session when using Horde_Session_Null sessions.

     Avoids the potential for session lock issues. See Bug: 11809

  framework/Core/lib/Horde/Session/Null.php |    6 ++++--
  1 files changed, 4 insertions(+), 2 deletions(-)

http://git.horde.org/horde-git/-/commit/645494515230ddfd89b435c711e480e7b0468a0c

This isn't actually a bug, but I haven't seen it documented anywhere.
I'm using Horde5 with Apache and mod_php. I've always chosen PHP file 
sessions to make tests, for simplicity.

When you choose push synchronization, your webserver uses a process to 
look for changes requested, and that process lives until a change is 
detected or until it reaches heartbeat seconds selected by ping 
command. Unfortunately, with file sessions this means the session file 
will be locked until process dies, so no other request from the same 
device can be replied. It will wait until first process dies and 
releases the lock on session file.

I've seen this when trying to access gal while another process is 
attending a previous ping command from the same device. As soon as 
ping finishes, gal results appear on my device.

If I choose memcache for sessions, these locking problems disappear, 
and requests from same device are processed as soon as they arrive to 
webserver.
This has been a very time consuming problem for me, as it prevents 
activesync from normal operation, and I think it should be clearly 
explained somewhere.