Does Infinispan support native operations for structured values like Redis? - redis

We're using Redis but considering Infinispan. Redis supports list, hashset, set, and sorted set, and offers native functions to operate over those structures, but does Infinispan support the same?
I know Infinispan will store any Java object, but Redis offers functions that operate on elements without having to explicitly retrieve them. I was wondering if Infinispan supports the same.

Infinispan does not support this out-of-the-box - there is some support for AtomicHashMaps, although I've heard that there may be issues with those.
The main feature you should be looking for is the DeltaAware interface - this allows you to build such collections, sending just the 'operation' that should be executed on the value.
There were some attempts to do so - check out infinispan-contrib (though I don't have any experience with that).

Related

#EnableRedisRepositories - What is the use of in Spring Data Redis?

I search a lot over web to get more practical usage of #EnableRedisRepositories, but I did not found any. Even in my Spring Boot + Spring Data Redis example, I removed #EnableRedisRepositories but still I did not understood what difference it make, still I can see data is persisting into DB and retrieving fine.
Can somebody please clarify ?
I went through this annotation, but not every clear..
Annotation to activate Redis repositories. If no base package is configured through either {#link #value()},
{#link #basePackages()} or {#link #basePackageClasses()} it will trigger scanning of the package of annotated class.
It lets Spring scan your packages for repository classes/interfaces and then use Redis as the storage to persist your objects to - instead of a classic relational database.
Spring Data docs tell us:
NoSQL storage systems provide an alternative to classical RDBMS for horizontal scalability and speed. In terms of implementation, key-value stores represent one of the largest (and oldest) members in the NoSQL space.
The Spring Data Redis (SDR) framework makes it easy to write Spring applications that use the Redis key-value store by eliminating the redundant tasks and boilerplate code required for interacting with the store through Spring’s excellent infrastructure support.

How to save semaphore in Aerospike?

We have been using Aeropsike exentsively as key-value store only. However now I couldn't find a way to actually save a lock in Aeropspike like the way we do in Redis.
I guess, I can always save native application lock as blobs, but that means I will be limited to a particular implementation in my application.
Don't believe you can "save" locks in Aerospike. Any form of locking has to be implemented at the Application level and then you have to deal with the locking client abandoning the lock.
I would suggest that you read Martin Kleppmann's Redlock Discussion. It covers the responses people in the distributed systems community had to Antirez's debating the topic, following Kleppmann's earlier article How to do distributed locking.
Building a DLM is not a trivial problem at all, and Redlock fails as one. If you are up for it, you can consider writing such a thing over the linearizable strong consistency mode of Aerospike Enterprise Edition 4.0.
As opposed to Redis and its variants, Aerospike EE 4.0 passes Jepsen.

Is there any SQL + Redis Hybrid ORM/OHM framework?

I can't find any related frameworks. For example, a hybrid ORM/OHM framework for Hibernate and Jedis (JAVA Framework). Is there some reasons that this kind of framework didn't appear yet?
Check
https://github.com/xetorthio/johm
JOhm is a blazingly fast Object-Hash Mapping library for Java inspired by the awesome Ohm. The JOhm OHM is a modern-day avatar of the old ORM's like Hibernate with the difference being that we are not dealing with an RDBMS here but with a NoSQL rockstar.
JOhm is a library for storing objects in Redis, a persistent key-value
database. JOhm is designed to be minimally-invasive and relies wholly
on reflection aided by annotation hooks for persistence. The
fundamental idea is to allow large existing codebases to easily plug
into Redis without the need to extend framework base classes or
provide excessive configuration metadata.
Durable data storage is available via the Redis Append-only file
(AOF). The default persistence strategy is Snapshotting.
Redis is the one of NoSQL database, and it doesn't support rich features provided by RDBs. (secondary index, grouping, query with multiple conditions, etc.) So naturally wrapping Redis operations with SQL doesn't make sense.
If you just want to have Object Mapper for Redis, spring-data-redis provides Serializer/Deserializer so you can store object to bytes in Redis, and load your data to object from Redis.

AWSDynamoDBObjectMapper or AWSDynamoDB?

The AWS documentation is seemingly endless, and different pages tell me different things. For example, one page tells me that AWSDynamoDBObjectMapper is the entry point to working with DynamoDB, while another tells me that AWSDynamoDB is the entry point to working with DynamoDB. Which class should I be using? Why?
EDIT: One user mentioned he didn't understand the question. To be more clear, I want to know, in general, what the difference is between using AWSDynamoDB and AWSDynamoDBObjectMapper as entry points to interfacing a DynamoDB.
Doc links for both:
AWSDynamoDB
AWSDynamoDBObjectMapper
Since both can clearly read, write, query, and scan, you need to pick out the differences. It appears to me that the ObjectMapper class supports the concept of mapping an AWSDynamoDBModel to a DB vs. directly manipulating specific objects (as AWSDynamoDB does). Moreover, it appears that AWSDynamoDB also supports methods for managing tables directly.
I would speculate that AWSDynamoDB is designed for managing data where the schema is pre-defined on the DB, and AWSDynamoDBObjectMapper is designed for managing data where the schema is defined by the client.
All of this speculation aside though, the most important bit you can glean from the documentation is:
Instead of making the requests to the low-level DynamoDB API directly from your application, we recommend that you use the AWS Software Development Kits (SDKs). The easy-to-use libraries in the AWS SDKs make it unnecessary to call the low-level DynamoDB API directly from your application. The libraries take care of request authentication, serialization, and connection management. For more information, go to Using the AWS SDKs with DynamoDB in the Amazon DynamoDB Developer Guide.
I would recommend this approach rather than worrying about the ambiguity of class documentation.

Xstream/HTTP service

We run multiple websites which use the same rich functional backend running as a library. The backend is comprised of multiple components with a lot of objects shared between them. Now, we need to separate a stateless rule execution component into a different container for security reasons. It would be great if I could have access to all the backend objects seamlessly in the rules component (rather than defining a new interface and objects/adapters).
I would like to use a RPC mechanism that will seamlessly support passing our java pojos (some of them are hibernate beans) over the wire. Webservices like JAXB, Axis etc. are needing quite a bit of boiler plate and configuration for each object. Whereas those using Java serialization seem straightforward but I am concerned about backward/forward compatibility issues.
We are using Xstream for serializing our objects into persistence store and happy so far. But none of the popular rpc/webservice framework seem use xstream for serialization. Is it ok to use xstream and send my objects over HTTP using my custom implementation? OR will java serialization just work OR are there better alternatives?
Advance thanks for your advise.
The good thing with standard Java serialization is that it produces binary stream which is quite a bit more space- and bandwidth-efficient than any of these XML serialization mechanisms. But as you wrote, XML can be more back/forward compatibility friendly, and it's easier to parse and modify by hand and/or by scripts, if need arises. It's a trade-off; if you need long-time storage, then it's advisable to avoid plain serialization.
I'm a happy XStream user. Zero problems so far.