or so
ago and there was much interest. I pointed people at our website.
Sent from my iPad
On 3 Oct 2013, at 18:16, Paolo Romano rom...@inesc-id.pt
mailto:rom...@inesc-id.pt wrote:
Hi all,
even the Cloud-TM project is officially over, we thought to share
with you one of our last efforts, which
, Mark Little m.c.lit...@ncl.ac.uk
mailto:m.c.lit...@ncl.ac.uk wrote:
FYI I presented on the current state of cloud-TM at HPTS a week or
so ago and there was much interest. I pointed people at our website.
Sent from my iPad
On 3 Oct 2013, at 18:16, Paolo Romano rom...@inesc-id.pt
mailto:rom
That would make *a lot* of sense :)
Cheers,
Paolo
On 6/19/13 1:44 PM, William Burns wrote:
All the L1 data for a DIST cache is stored in the same data container
as the actual distributed data itself. I wanted to propose breaking
this out so there is a separate data container for the L1
to either option... I think there are pros and cons either way.
Thanks!
matt
On Mon, Mar 4, 2013 at 7:07 AM, Paolo Romano rom...@inesc-id.pt
mailto:rom...@inesc-id.pt wrote:
This sounds really interesting Matt. In the Cloud-TM project
(www.cloudtm.eu http://www.cloudtm.eu/) we
Congrats to the team!
Cheers
Paolo
On 4/10/13 1:30 AM, Mircea Markus wrote:
Highlights:
- total order protocol for transactions
- JSR-107 support
- Lucene directory implementation based on Lucene 4
- packaging for the Infinispan server modules
Wanna know more?
application.
Regards,
Paolo
--
Paolo Romano, PhD
Coordinator of the Cloud-TM ICT FP7 Project (www.cloudtm.eu)
Senior Researcher @ INESC-ID (www.inesc-id.pt)
Assistant Professor @ Instituto Superior Tecnico (www.ist.utl.pt)
Rua Alves Redol, 9
1000-059, Lisbon Portugal
Tel. + 351 21 3100300
Fax + 351
If you're really into self-tuning this parameter, I expect that a very
simple gradient-descent mechanism would actually work pretty well in
this case.
We have done similar work in the Cloud-TM project (applied to both
message batching and number of threads active per node), and if you're
Congratulations!
Paolo
On 1/31/13 8:51 PM, Mircea Markus wrote:
Hi,
I am pleased to announce the much awaited final release of Infinispan
5.2.0. Containing more than 100 features and enhancements and 150 bug
fixes [1], this release the sustained effort of engineering, QA and
our
Another alternative solution would be to have a STM-backed
implementation of a hash table. For instance, some colleagues of mine
have developed a B+ tree implementation using JVSTM [1].
Benchmarking the performance of such a solution should be relatively fast.
Common sense suggests that a
NBST was introduced [https://issues.jboss.org/browse/ISPN-2312]
On 09/14/20 12 07:51 PM, Paolo Romano wrote:
Hi all,
with Pedro we have been reasoning on the integration of TO-based
replication protocols, and a few questions popped out.
We may be missing something here, but it seems
Hi all,
with Pedro we have been reasoning on the integration of TO-based
replication protocols, and a few questions popped out.
We may be missing something here, but it seems that the current NBST
implementation is still not providing support for pending transactions,
namely transactions
Even though I am not sure that behaviour a) is strictly mandated by ANSI
SQL Read Committed Isolation Level, I agree with Jonathan: if a
transaction is not even guaranteed to see its own writes one may start
wondering what's the purpose of even calling it a transaction...
On the other hand,
It looks very interesting Mircea.
Do you plan to support update operations on remote backups? May be you
have already some additional design documentation on this feature?
Cheers,
Paolo
On 7/6/12 2:06 PM, Mircea Markus wrote:
Hi,
This[1] is the first draft of the cross-site (x-s)[2]
Hi Dan, Mircea,
the Cloud-TM review is in less the a month and we need to have the state
transfer working properly also for TOB/TOM replication/distribution.
With Pedro, we have prepared a design document describing how we think
that it could be implemented:
Hi Galder,
Let me try to clarify this. With Diego we have developed a system for
forecasting the performance (e.g. maximum throughput, abort rate, avg.
transaction execution time) of an ISPN application when it is deployed
on a cluster of a different scale (compared to the current one).
We
On 5/15/12 5:20 PM, Galder Zamarreño wrote:
On May 15, 2012, at 4:58 PM, Paolo Romano wrote:
Hi Galder,
Let me try to clarify this.
With Diego we have developed a system for
forecasting the performance (e.g. maximum throughput, abort rate, avg.
transaction execution time) of an ISPN
On 5/15/12 5:21 PM, Manik Surtani wrote:
On 15 May 2012, at 17:10, Galder Zamarreño wrote:
You have not yet given me a single reason why we should put back
something that's flawed. All you've said is: i rely on X and I want
it back.
Well, the old scheme was broken and there are several
Hi Dan,
the easiest way to me seems to treat the state transfer as a special
transaction that is TO-broadcast using the sequencer, as you have also
been suggesting in your email.
I guess that this way you may even get rid of the ST lock, as
transactions that request a commit after a ST is
On 3/23/12 10:45 AM, Bela Ban wrote:
The biggest problem I remember total order having is TM transactions
that have other participants (as opposed to cache-only transactions).
I haven't followed the TO discussion on the mailing list very closely,
does that work now?
No, I don't think that's
Hi Mircea,
if I recall correctly currently (with 2PC) the commit is sent
asynchronously (without waiting to gather acks). If this is correct,
then the transaction originator can return from a commit on a
transaction T before other nodes have actually applied T's updates.
Therefore, the
I did not know about this change, thanks for pointing it out! By the
way, is it still possible to send commit messages asynchronously with
2PC by changing the default config? I am asking as, in order to ensure
fairness when comparing the performance of the two protocols, it would
be better to
Good, this means that those results were based on a fair comparison!
Paolo
On 3/7/12 6:49 PM, Pedro Ruivo wrote:
BTW, the results posted, both configurations had the flag
syncCommit/RollbackPhase set to false.
On 3/7/12 1:41 PM, Paolo Romano wrote:
I did not know about this change
in future to avoid deadlocks.
I presume you still support full JTA semantics over GMU?
I presume it too ;-)
Cheers,
Paolo
Cheers
Manik
On 29 Nov 2011, at 13:11, Paolo Romano wrote:
Hi,
within the context Cloud-TM project we have developed a new partial
replication algorithm
On 12/10/11 11:46 AM, Sebastiano Peluso wrote:
Hi Manik,
in order to provide correct answers to your questions, I want to ask
you the following:
- Why do you say that the current MVCC implementation is non-genuine?
I think that for any transaction T, only the sites that replicate the
data
On 12/6/11 11:46 AM, Galder Zamarreño wrote:
Hi,
Re: https://github.com/infinispan/infinispan/pull/697#r272846
When in place, I'd like to use the ability to provide a version externally
with Hibernate in order get versions to come from Hibernate.
As indicated by
On 12/7/11 5:00 PM, Sanne Grinovero wrote:
On 7 December 2011 16:50, Manik Surtanima...@jboss.org wrote:
On 7 Dec 2011, at 16:45, Sanne Grinovero wrote:
We need to pick some solid names. Logical lock sounds good for the
user visible locks ? Internal Lock for our own?
Data Lock and
Hi,
one more result from the Cloud-TM project that we thought might be
interesting for the Infinispan community (and possibly OpenShift).
Our last effort is a system for automating elastic scaling for
Infinispan, which we named TAS: Transactional Auto Scaler.
TAS uses a hybrid methodology
/ficheiros/publicacoes/7549.pdf
Comments are more than welcome of course!
Cheers,
Paolo
--
Paolo Romano, PhD
Coordinator of the Cloud-TM ICT FP7 Project (www.cloudtm.eu)
Senior Researcher @ INESC-ID (www.inesc-id.pt)
Invited Professor @ Instituto Superior Tecnico (www.ist.utl.pt)
Rua Alves Redol
On 11/8/11 8:16 AM, Galder Zamarreño wrote:
On Nov 7, 2011, at 5:27 PM, Sebastiano Peluso wrote:
By the way, one last thing:
On Nov 7, 2011, at 1:14 PM, Sebastiano Peluso wrote:
Hi Galder,
thank you for the review. My answers are below inline.
Il 04/11/11 11:02, Galder Zamarreño ha
Cool stuff Mircea! ;-)
We're actually planning for rebasing our total-order based schemes on
this pull, so we look forward to seeing it finalized!
Have you already implemented any mechanism to avoid consistency issues
related to inversions of the delivery order of commit messages at
On 9/16/11 12:58 PM, Manik Surtani wrote:
On 15 Sep 2011, at 15:41, Paolo Romano wrote:
Do you want to increase the value stored in the i-th entry of each
data item updated by a committing transaction independently (i.e.
data_item.VC[i]=data_item.VC[i]+1 instead of
data_item.VC[i
Interesting stuff Manik, thanks for the updates. Actually, on our side
we've also been working on adding versioning to ISPN during the summer.
However, in our case we are aiming at achieving serializability avoiding
global synchronization points (so we're actually keeping chains of
versions
On 9/15/11 2:51 PM, Manik Surtani wrote:
On 15 Sep 2011, at 14:44, Paolo Romano wrote:
Concerning costs. For option 2), the prepare message should piggyback
the version identifiers of *each* data item that needs to be write-skew
checked...which may lead to big messages, if you needed to test
On 7/5/11 3:47 PM, Mircea Markus wrote:
On 5 Jul 2011, at 15:39, Manik Surtani wrote:
Good stuff, shame about the RPC count . ;)
yeah. Still very valid when there are deadlocks, guess figures will tell us
more precisely what the gain is
I agree with Manik's observation.
When benchmarking
There has been a lot of discussion on this topic also in the
Transactional Memory area, triggered to the best of my knowledge by this
paper [1].
Mixing transactional and non-transactional access to shared state opens
a number of subtle scenarios and there are a pile of follow-up papers on
other cool phrase to highlight the
relevance of Infinispan in the NoSQL data grid domain!
Cheers,
Paolo
--
Paolo Romano, PhD
Coordinator of the Cloud-TM ICT FP7 Project (www.cloudtm.eu)
Senior Researcher
INESC-ID
Rua Alves Redol, 9
1000-059, Lisbon Portugal
Tel. + 351 21 3100300
Fax
On 4/20/11 7:25 PM, Manik Surtani wrote:
On 20 Apr 2011, at 18:18, Paolo Romano wrote:
On 4/17/11 7:55 PM, Manik Surtani wrote:
Excellent stuff, Paolo and Pedro. My comments below, inline. Cc'ing
infinispan-dev as well.
Thanks Manik!
On 16 Apr 2011, at 21:47, Paolo Romano wrote:
...
I
37 matches
Mail list logo
