Persistance plus efficace de UserAgent
A la réception de messages provenant d'un topic (TopicMsgsReply, TopicDeliveryTimeNot) ou d'un ordre de commit provenant d'un client JMS (CommitRequest), une sauvegarde du UserAgent est faite. Cette sauvegarde pourrait être évitée ou faite de manière plus efficace :
1- TopicMsgsReply: un compteur d'arrivée de message ("arrivalsCounter") est incrémenté. Est-ce que la sauvegarde de ce compteur est nécessaire ? Si oui, il faudrait séparer la persistance de ce compteur du reste de l'état du UserAgent qui est potentiellement volumineux. Si non, il suffit de ne pas sauvegarder le UserAgent.
2- CommitRequest: la sauvegarde de UserAgent semble être inutile dans ce cas.
3- TopicDeliveryTimeNot: idem.
Il y a peut-être encore d'autres cas à optimiser. Je pense que plus généralement, la persistance de UserAgent doit être modulaire afin d'éviter de sauvegarder systématiquement un gros volume de données.
Des commentaires lèvent déjà le doute au sujet de ces sauvegardes :
"// TODO (AF): is it needed to save the proxy ?"
"// TODO (AF): The message saving does it need the proxy saving ?"
De plus, depuis que la persistance de ClientSubscription est séparée de celle de UserAgent, ces sauvegardes ne semblent plus nécessaires.
Le test SpecJMS crée beaucoup de clients pour un même UserAgent entraînant un état assez gros, en particulier la table 'subsClientIDs' reliant les noms de souscriptions au 'clientId'. En conséquence, les sauvegardes décrites ci-dessus pénalisent le fonctionnement de Joram.
[JORAM-166] created at 2013-11-29 15:46:35 by feliot, version JORAM_5_9_1