[
https://jira.jboss.org/jira/browse/ISPN-256?page=com.atlassian.jira.plugi...
]
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