On Nov 8, 2013, at 4:28 PM, Mircea Markus mmar...@redhat.com wrote:
Hey guys,
Several things were discussed lately([1],[2],[3],[4]) around our transaction
support. Here's some some thoughts I have around re-modeling transactions for
7.0:
1. Async options for commit/rollback
- they
On Nov 12, 2013, at 12:43 PM, Martin Gencur mgen...@redhat.com wrote:
+1 for all these suggestions. Configuring transactions in Infinispan is
overly complex (too many options). Some of the configurations were
supposed to provide better performance and they actually don't provide
that,
Hi all,
I would like to use the Infinispan modules in WildFly, but the ones
being distributed by the Infinispan project are still targeting EAP
(older application server 7.x).
Could we please migrate to using WildFly for integration tests?
Currently Hibernate Search is packing the
On Nov 12, 2013, at 12:56 PM, Galder Zamarreño gal...@redhat.com wrote:
On Nov 8, 2013, at 4:28 PM, Mircea Markus mmar...@redhat.com wrote:
Hey guys,
Several things were discussed lately([1],[2],[3],[4]) around our transaction
support. Here's some some thoughts I have around
Mircea, besides mentioning of removed stuff, would it be possible to
compile some list of supported transactional modes and *expected
behaviour*? (using short code snippets: in one mode this will fail, in
other one succeed) Ideally, total order could be included there as well.
This list should
On Nov 11, 2013, at 3:09 PM, Sanne Grinovero sa...@infinispan.org wrote:
We discussed this offline, so to let everyone else know:
I had opened that one issue on behalf of Galder while he was on
vacations, as for my opinion it looked like a blocker to be able to
pass the certification for
Yet one more request: clear behaviour should be specified there as well
- there was some discussion about txs and clear few months ago (I think
fired by Sanne), but I have a feeling that it just got burried in the
mailing list without any concrete result.
Radim
On 11/12/2013 01:26 PM, Radim
On 12 November 2013 12:31, Radim Vansa rva...@redhat.com wrote:
Yet one more request: clear behaviour should be specified there as well
- there was some discussion about txs and clear few months ago (I think
fired by Sanne), but I have a feeling that it just got burried in the
mailing list
On Nov 12, 2013, at 1:26 PM, Radim Vansa rva...@redhat.com wrote:
Mircea, besides mentioning of removed stuff, would it be possible to
compile some list of supported transactional modes and *expected
behaviour*? (using short code snippets: in one mode this will fail, in
other one succeed)
On 11/12/2013 02:46 PM, Mircea Markus wrote:
On Nov 12, 2013, at 1:26 PM, Radim Vansa rva...@redhat.com wrote:
Mircea, besides mentioning of removed stuff, would it be possible to
compile some list of supported transactional modes and *expected
behaviour*? (using short code snippets: in one
On Nov 12, 2013, at 3:09 PM, Radim Vansa rva...@redhat.com wrote:
On 11/12/2013 02:46 PM, Mircea Markus wrote:
On Nov 12, 2013, at 1:26 PM, Radim Vansa rva...@redhat.com wrote:
Mircea, besides mentioning of removed stuff, would it be possible to
compile some list of supported transactional
Would these changes impact the WildFly transaction mode [5]? Is the
WildFly NON_XA transaction mode mapping to the 1PC option? Or Does
WildFly NON_XA map to something else in Infinispan?
I'm not sure how this would impact WFLY-2267 [6], which is about
attempting to register a synchronization
Hi,
I'm working on the integration between HotRod and OGM.
We already have a dialect for Inifinispan and I'm trying to follow the same
logic.
At the moment I'm having two problems:
1) In the Infinispan dialect we are using the AtomicMap and the
AtomicMapLookup but this classes don't work with
Hi Scott,
On Nov 12, 2013, at 3:29 PM, Scott Marlow smar...@redhat.com wrote:
Would these changes impact the WildFly transaction mode [5]? Is the
WildFly NON_XA transaction mode mapping to the 1PC option?
no, that only has to do with the way transactions are enlisted with the
transaction
On the transaction side, we can start without them.
On Tue 2013-11-12 14:34, Davide D'Alto wrote:
Hi,
I'm working on the integration between HotRod and OGM.
We already have a dialect for Inifinispan and I'm trying to follow the same
logic.
At the moment I'm having two problems:
1) In
On 11/12/2013 11:56 AM, Galder Zamarreño wrote:
On Nov 8, 2013, at 4:28 PM, Mircea Markus mmar...@redhat.com wrote:
Hey guys,
Several things were discussed lately([1],[2],[3],[4]) around our transaction
support. Here's some some thoughts I have around re-modeling transactions
for 7.0:
On 11/08/2013 03:28 PM, Mircea Markus wrote:
Hey guys,
Several things were discussed lately([1],[2],[3],[4]) around our transaction
support. Here's some some thoughts I have around re-modeling transactions for
7.0:
1. Async options for commit/rollback
- they don't really make sense as
On 12 November 2013 14:54, Emmanuel Bernard emman...@hibernate.org wrote:
On the transaction side, we can start without them.
+1 on omitting transactions for now.
And on the missing AtomicMaps, I hope the Infinispan will want to implement it?
Would be good to eventually converge on similar
On 11/12/2013 12:26 PM, Radim Vansa wrote:
Mircea, besides mentioning of removed stuff, would it be possible to
compile some list of supported transactional modes and *expected
behaviour*? (using short code snippets: in one mode this will fail, in
other one succeed) Ideally, total order
Hi all,
Re: https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
I've just finished writing up the Hot Rod remote events design document.
Amongst many other use cases, this will enable near caching use cases with the
help of Hot Rod client callbacks.
Cheers,
--
Galder Zamarreño
20 matches
Mail list logo
