Artyom Kravchenko created CAY-2195:
--------------------------------------
Summary: ROP: restore CayenneContext.userProperties in server
context during client commit
Key: CAY-2195
URL: https://issues.apache.org/jira/browse/CAY-2195
Project: Cayenne
Issue Type: Task
Affects Versions: 4.0.M3
Environment: Cayenne ROP, ProtostuffROPSerializationService,
HttpROPConnector
Reporter: Artyom Kravchenko
Hi dear cayenne developers.
I want to to use CayenneContext.userProperties - set it on client side and get
it on server during some listeners or filters execution. I need it to handle
client commits in different ways (in depends on userProperties): create
additional records, make some validation and other (in accordance with my
business requirements).
As I see this is not works as I expect: any userProperties which I set up in
client context do not accessible on server.
I have looked on this issue deeper and discover that:
- ClientServerChannel(singleton per client) store serverContext (also
singleton) instance and use this instance for any ROP actions (Sync/Query). In
my case all client changes (GraphDiff changes) will be restored in
serverContext and all subsequent operations (filters/listeners/callbacks) will
use exactly serverContext - do not know anything about client context (named
as 'originatingContext' in cayenne), moreover about userProperties.
- ClientMessage (SyncMessage in my case) has a reference on client context
(source). On client side SyncMessage initialized properly, but after
deserialization (by ProtostuffROPSerializationService on server side) the
source (client context) are lost - null value.
Yes, I know that source (client context) is not uses in any place on server
side (use serverContext for any ROP operations as described above), but this is
good place I would extract some useProperties from.
One more question is how cayenne ROP implements queue for client actions (e.g.
this is multithreading client app) since ClientServerChannel use the same
instance of serverContext for any client action. This is reasonable that
different threads can change serverContext state simultaneously.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
