[infinispan-issues] [JBoss JIRA] Commented: (ISPN-256) Enable Infinispan SPIs to implement their own commands

[Manik Surtani (JIRA)]

    [ https://jira.jboss.org/jira/browse/ISPN-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12493282#action_12493282 ] 

Manik Surtani commented on ISPN-256:
------------------------------------

Hmm; the problem with this is that it then makes infinispan a message bus.  Completely not what it is designed to do, but I can see how it could aid other use cases.  

Anyway, what you would need is like you said an ExtensionCommand, which could contain an arbitrary payload of Serializable[], a target cache, and a mechanism to register a listener for such ExtensionCommands.  And also a mechanism of dispatching such commands: dispatchExtensionCommand(ExtensionCommand ec, List<Address> recipients, boolean sync) ?


> Enable Infinispan SPIs to implement their own commands
> ------------------------------------------------------
>
>                 Key: ISPN-256
>                 URL: https://jira.jboss.org/jira/browse/ISPN-256
>             Project: Infinispan
>          Issue Type: Feature Request
>            Reporter: Galder Zamarreno
>            Assignee: Galder Zamarreno
>             Fix For: 4.1.0.BETA1
>
>
>  Much nicer IMHO would be a nice SPI / plug point to allow applications to extend the set of commands. Let an app create an ExtensionCommand; if that comes in off the channel pass it off to the handler the application registered.
> This could for example be used instead of the solution currently used in http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818. In HHH-3818, the cache is used as a notification vehicle which is a bit of a hack and has some limitations for example when trying to implement a similar solution for evict(key) op.
> Another use case for it would be HTTP session ownership, from Brian Stansberry:
> (09:32:09 AM) brian_stansberry: ... it's just that only 1 server at a time s/b able to use a session
> (09:32:25 AM) brian_stansberry: so on failover i send an extension command requesting ownership
> (09:33:19 AM) brian_stansberry: there's actually a servlet spec requirement that only one server at a time access a session
> (09:33:23 AM) brian_stansberry: ejb spec too
> (09:33:37 AM) brian_stansberry: we don't properly handle that
> ...
> (09:34:18 AM) brian_stansberry: basically it's a lock
> ...
> (09:34:35 AM) brian_stansberry: that's all it is, a distributed lock
> (09:35:03 AM) brian_stansberry: but once you have the distributed lock it's yours until you give it up
> (09:35:29 AM) brian_stansberry: so once 1 request acquires it, subsequent requests to same server can just use a local lock
> ...
> (09:41:59 AM) brian_stansberry: the key thing is there should only be a cluster-wide operation once per session
> (09:42:11 AM) brian_stansberry: unless there is failover

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira