I want to perform some batch operations in JCR (Jackrabit), I need to use org.apache.jackrabbit.spi.Batch (docs), for this I need RepositoryService but I do not know how to obtain the RepositoryService.
RepositoryService is a low-level interface, used by the Jackrabbit SPI interfaces.
In general, you do batch operations in JCR by do several operations and then calling Session.save().
Related
I want to implement Distributed caching(Redis) in ASP.NET Core project. After a bit or research I found that there are two ways of creating a Redis connection using AddStackExchangeRedisCache in Startup.cs and ConnectionMultiplexer
AddStackExchangeRedisCache - This happens in Startup.cs.
Doubts in above approach:
Does this work in Prod environment?
When and how the connection is initialized?
Is it thread safe way to create the connection?
By using the ConnectionMultiplexer, we can initialize the DB instance. As per few articles, Lazy initialization will take care of the Thread safety as well
Doubts:
From above approaches, which is the better approach?
I tried both approaches in my local machine both are working fine. But I could not find Pros and Cons of above approach.
With ConnectionMultiplexer, you have the full list of commands that you can execute on your Redis server. With DistributedCaching, you can only store/retrieve a byte array or a string, and you can not execute any other commands that Redis provides. So if you just want to use it as a cache store, DistributedCaching provides a good abstraction layer. However, even the simplest increment/decrement command for Redis will not be available, unless you use ConnectionMultiplexer.
The extension method AddStackExchangeRedisCache uses a ConnectionMultiplexer under the hood (see here, and here for the extension method itself).
#2: works in prod either way
#3: connection is established lazily on first use, the ConnectionMultiplexer instance is re-used (registered as DI singleton)
#4: yeah, see above resp. here, a SemaphoreSlim is used to ensure the connection is only created once
pros and cons: since both use the ConnectionMultiplexer, they are pretty similar.
You can pick between the advantages of using the implementation agnostic IDistributedCache vs. direct use of the multiplexer and the StackExchange.Redis API (which has more specific functions than the interface).
Wrappers like IDistributedCache and StackExchangeRedis.Extensions do not include all the functions possible in the original library, In particular I required to delete All the keys in Redis Cache, which was not exposed in these wrappers.
Do you know if it is possible to do the following using springDataGemfire:
#Query("$1")
List<String> getQuery(String Query);
we are trying to build a dynamic query and then run it on GemFire
we are getting the below error :
org.springframework.dao.InvalidDataAccessApiUsageException: Result object returned from GemfireCallback isn't a SelectResult:
Best regards,
Farid
Farid-
The SD[G] Repository infrastructure and extension for Pivotal GemFire, and in particular, the explicit OQL query using the #Query annotation, was never meant to be used in this way.
Essentially, you are attempting to use the SD Repository infrastructure to run "ad hoc" GemFire OQL queries, therefore, why not use the GemfireTemplate directly, or even GemFire's QueryService API for this purpose?
What you are attempting to do is akin to using Hibernate for complex queries beyond mapping and ordinary queries (which is not really the purpose of Hibernate) when JDBC directly (or Spring's JdbcTemplate) is more appropriate for advance querying capabilities.
It is still possible to use a hybrid approach though, where the "provided" SD Repository infrastructure handles the majority of your application's data access patterns (e.g. CRUD, simple queries, etc) and you combine that with a "custom" Repository implementation.
I have an example of such a "custom" Repository implementation for GemFire in my Contacts Application RI for SDG, here. The CustomerRepository extends CustomerRepositoryExtension, which is implemented in the CustomerRepositoryImpl class. SD's Repository infrastructure picks up this "custom" implementation when creating the Repository proxy for the CustomerRepository interface. In this case, I am having the "custom Repository data access/query method call a GemFire Function (as can be seen here).
In your case, it is a simple matter to run the passed in, dynamic OQL query using the SDG GemfireTemplate or GemFire's QueryService API directly.
Hope this helps!
-John
I see that Jedis and JedisCluster don't implement a common java interface, and I am wondering why. My software will be running in different environments where redis may or may not run in cluster mode, so how do I implement a common piece of code using Jedis that will run in both the environments?
The clients will be doing only basic operations and I want to hide the cluster operations within the library and not expose them. Any ideas on a modular design?
thanks.
Looks like this may be your answer redis.clients.jedis.JedisCommands.
You can use this interface as argument to your methods and pass in either a Jedis or JedisCluster instance.
I am try to develop a Hazelcast Client. This client will connect a cluster and display objects' values in Collections. Problem is that client will not know classes in cluster. Can I create dynamically these classes and use in my Hazelcast Client? I tried Hazelcast serialization and reflection but I did not succeed.
First, plz have a look at the existing client implementations. Clients have been implemented in many programming languages, thus maybe you don't have to implement the client again.
Now, when it comes to your question: it is not a problem if you store primitive data types in your Collection, e.g. String, Integer, etc.
If you store custom classes, let them implement Portable or IdentifiedDataSerializable. It will enable creating the same data structures on the client side. Have a look at the C++ serialisation example:
http://docs.hazelcast.org/docs/3.6/manual/html-single/index.html#c-client-code-examples
In an n-tier architecture, the best place to put an object-relational mapping (OR/M) code is in the data access layer. For example, database queries and updates can be delegated to a tool like NHibernate.
Yet, I'd like to keep all references to NHibernate within the data access layer and abstract dependencies away from the layers below or above it. That way, I can swap or plug in another OR/M tool (e.g. Entity Framework) or some approach (e.g. plain vanilla stored procedure calls, mock objects) without causing compile-time errors or a major overhaul of the entire application. Testability is an added bonus.
Could someone please suggest a wrapper (i.e. an interface or base class) or approach that would keep OR/M loosely coupled and contained in 1 layer? Or point me to resources that would help?
Thanks.
It sounds like you are looking for the repository pattern. If you need more decoupling, you can inject the data dependencies with an Inversion of Control container.
Service Facade Pattern is one name. Simple contracts between business logic and data layer.
Service classes or beans (call it what you want) define and implement the contract, and orchestrate the lower data layer, often handling the transactional logic across data objects.
In Spring, you define an Interface, and then implement it. One implementation might be an OR/M, another might be raw JDBC or ADO.NET. In some frameworks, Aspect Oriented Programming allows you to inject declarative transactional logic without writing any code. It saves a lot of headache.
One caveat: When dealing with some OR/Ms like Hibernate, there is the use of proxy classes. This does pollute things, because there are a few instances where the proxy classes cause problems. In my opinion, that is an implemtation detail that should not escape the service layer. But with Hibernate, it does. Not sure about the .NET implementation.