The details regarding your configuration is less the complete here. There are many possible scenarios under which this can happen. One of the more likely situations is that, the code snippet above is perhaps a client cache where /HTTPAudit is a PROXY Client Region to some peer Server Region (data policy unclear, although not as important if this is a client/server topology in play).
Because your HTTPAudit implements java.io.Serializable, GemFire will use Java Serialization to send the object over the wire.
GemFire will then store the object in the "form" that it got (in this case Serialized).
Next, you go onto run a OQL statement (Query) and proceed in accessing a field on the object (sessionId). Because GemFire cannot access data in a "Java Serialized" form, it must deserialize the value to inspect it for the predicate of the Query.
In this case, I am guessing your "GemFire Server" node does not have the HTTPAudit class on the CLASSPATH, which it needs.
If you want to avoid the deserialization of the HTTPAudit object on the GemFire Server when an OQL like the one above is issued, then you should switch to PDX Serialization (http://gemfire.docs.pivotal.io/latest/userguide/developing/data_serialization/gemfire_pdx_serialization.html), and set the Server's configuration 'read-serailized' attribute to true.
However, you should be careful since not all OQL operations on an object necessarily keep the object in serialized form, even when using PDX.
For instance, an OQL Query similar to...
SELECT audit.toString() FROM /HTTPAudit audit WHERE ...
Would cause even a PDX serialized object to be deserialized during Query execution.
Not that calling toString() is good practice (it is merely to demonstrate a point), but certain object operations can cause GemFire to deserialize a value to perform the object operation in the OQL statement during processing, even when stored in the PDX serialized form, which would thus require the class to be on the Server's CLASSPATH. So, be careful.
However, in your case, the problem is caused because you are using the less efficient, though more standard, Java Serialization to store and access your object. Unlike PDX serialization, there is no "type metadata" that enables GemFire to access data on the object in serialized form without having to "deserialize" it first. With Java Serialization, GemFire must deserialize the object to access it's information.
Hope this helps.