Implementing Caching in existing application - java

If I am supposed to implement Caching in existing Spring application for all web service as well as database call, what would be the best way to implement it? I mean any of the design patterns and caching mechanism that can be used with other required stuffs.
I would appreciate any suggestion provided.

Since you are already using Spring stack, Spring Caching could be a alternative you can consider as it will require very less integration and most of the things come out of the box. You can take a look at simple examples here and here too to get a feel of how it works. However if you want more control on the actual underlying cache implementation and the code to interact with that you can roll out your own easily too, though that will require more code to write at your end.

If you are using springboot you can use the
#EnableCaching and #Cacheable
Since Spring Boot automatically configures a suitable CacheManager to serve as a provider for the relevant cache.
You can find more on https://spring.io/guides/gs/caching/

In addition to Guru's answer.
You can find more info about Spring Boot Caching on https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-caching.html and https://docs.spring.io/spring/docs/4.3.14.RELEASE/spring-framework-reference/htmlsingle/#cache
#EnableCaching is for configuration and #Cacheable is for trigger cache object.

Related

How many proxies created in Java application use Spring core, Hibernate, Spring AOP?

I'm reading about Java proxy and as we know Spring Core, Hibernate, Spring AOP, Ehcache is an implement of it. I have got confused cause SpringCore will create a proxy, Hibernate will create a proxy and SpringAOP or Ehcache will do the same if we use all of them in a Java project.
How many proxies will create? Can someone help me out this problem and give me some example?
Each of those frameworks create any variable number of proxies all based upon certain design choices and configurations. That said, the only way to have any idea would be to profile your application.
Most frameworks that use proxies leverage them for similar reasons. These proxies are meant to act as placeholders that look like an object our code knows about and works with; however the internal implementation details are hidden, often supplemented with framework specific business logic.
For example, hibernate may expose a lazily-loaded collection of objects as a collection of proxies. Each proxy looks like the object our application expects in that collection; however, the internal state of that proxy is often not yet loaded until first accessed. In this case, the proxy saves on memory consumption, result-set parsing and database bandwidth, and a plethora of other things.

Schema multitenancy in Dropwizard

Is there a way to implement schema multi tenancy in dropwizard?
The only solution I've found so far is https://github.com/flipkart-incubator/dropwizard-multitenancy but that is using descriminator multi tenancy.
We basically had the same problem. We wanted to support multi-tenancy, but not only on database level. Different customers have certain services configured differently. In order to avoid passing through the tenancyId everywhere, we came up with a custom scope using Guice. This way, every service that is #TenancyScoped can get its own predefined configuration or simply the tenancyId in its constructor. Then your DAOs can use different schemas based on the tenancyId.
It works quite well for us, even though it might not properly scale if you have too many (maybe > 1000, really depends how complex your configuration is) tenants.
I have posted the details about Guice and custom scopes here: Multi tenancy with Guice Custom Scopes and Jersey.
I had the same problem and I created a multitenant hibernate bundle by modifying the current hibernate bundle code. If you still have the requirement you can check it out.
Here is the link: https://github.com/uditnarayan/dropwizard-hibernate-multitenant/

What are pros and cons of using Spring in Swing based frontend

we have a frontend application that that uses Swing. We use Spring framework, but currently it is used just to autowire few beans...
What are reasonable next steps to use Spring more often?
Is it worth for non web application?
What would be advantages and disadvantages?
The advantages of using Spring (or any other dependency-injection) framework, is that you get a (hopefully) loosely coupled system, i.e you classes does not create instances of their collaborators, so you can easily change the implementation.
This is widely known as the Inversion-of-control principle (IoC, also the I in SOLID), and this is a good principle to follow. This means that spring is not limited to web applications, but can be used in any application that want to use an IoC-container (which is basically what spring-core is).
Disadvantages:
This really depends on how you look at things. There is more code (you have to define a entry-point for the injected collaborators), but that also makes the code more testable (the entry-points are seams which you can use to inject mocks and stubs in testing).
Also, you can't look at the code and immediately see which implementation of the collaborators that are used. But that also makes for good code, since you depend on interfaces, not implementations.
You get more config: either in an xml-file (old-style spring), or with annotations. Up until recently you had to rely on non-standard spring annotations to inject (#Autowired) resources, but now you can use the standard java dependency injection annotations, which means that you can switch out spring as your IoC-container without changing your code.
There are probably alot more advantages and disadvantages to using spring in your application, but this should get you started on deciding if using Dependency Inversion is a good thing for your application
More to the point of your question about Swing and Spring. In an application I have been working on we have been using spring to wire up the whole application. The different dialogs get their logic injected (no application logic should (in my opinion) be located together with gui logic). We are using JPA/hibernate as the database-layer, so we use spring spring to create and inject the entitymanager to our DAOs, and set up transactional settings.
I've written swing UI's that are backed by spring.
cons
the startup can be slower but you have to have a large app for that to happen.
and a splashscreen is a good idea in those situations.
its easy to "overbean" or over-zealously make everything a bean, which gets messy.
pros
spring works fine behind a GUI.
it provides a lot of services you can use
the obvious dependency injection and decoupling
a global event system, simpifying some of your own event listeners, for events that will only ever be fired by one source
resource accessing
database access is eays in 2 tier apps
rpc for 3 tier apps is easy
There are other services the spring application context provides, but that I haven't used.
If you go this direction, also look into the java-based configuration for spring, which is new in 3.0. I find that helpful as well, as it makes my spring configuration type-safe.
One disadvantage of using Spring in a Swing application is that Spring DI will make startup slower.
well one would be , if you ever decide to migrate to a web app , all you need ( well almost) to change would be the views. That's the beauty of MVC applications.

How to create security anotation like spring security

i wonder how to create security annotation like spring security does (#PreAuthorized or #Secured) that will check session than do something to decide how application will threat the authority to log on user.
is any resource i can read or any recommendation?
best regards
ps: for some reason, i cannot use spring security
The technique behind these annotations is called Aspect Oriented Programming (AOP).
Spring Security relies on Spring AOP, which allows you to intercept particular method calls on Spring-managed object, so that you can apply security checks to them.
See Aspect Oriented Programming with Spring. Alternatively, if you want to do it without Spring, see standalone AOP implementations such as AspectJ.
The best tutorial for 'how does Spring Security work' is 'the source of Spring Security'. It is open source. You can read it. Honestly, the question as posed is much to broad to allow for much more of an answer.

Which one to use: OpenSessionInViewInterceptor or OpenSessionInViewFilter?

I'm having a hard time deciding which "Open Session In View" to use: configuring OpenSessionInViewInterceptor using Spring MVC's interceptor with or configuring OpenSessionInViewFilter in web.xml's filter? From what I have researched, they do pretty much the same thing, but I'm trying to understand the difference and the usage of each type.
The biggest difference between the two is for folks who can't use a filter in web.xml (say, servlet 2.2 and earlier), their only option is to use OpenSessionInViewInterceptor. Somehow, I'm leaning towards the interceptor simply because I have to create a custom interceptor for my project, so I'm thinking of grouping all these "filters" in Spring MVC config file rather than having OpenSessionInViewFilter in web.xml and my custom interceptor in Spring MVC config file. It's really a lame way to decide which one to use, and my curiosity kills me here.
Can anyone share your thoughts about this? Which one do you guys use?
Thanks.
As you say, the two are more or less equivalent. Spring provides them both so that you can pick the one that fits best with your existing application.
If you use Spring MVC, then it makes sense to use the interceptor, since it's easier to configure and better integrates with Spring MVC.
However, if you don't use Spring MVC, and only use Spring at the business-logic level, then the interceptor isn't really an option, and the filter becomes more appropriate. Because filters are not managed by Spring, they're harder to configure to integrate with Spring, but that's the trade-off.
If you have any requests that are not going to go through a spring controller, i.e. legacy code that goes through a custom servlet, or jsp's that are hit directly, then the filter will cover those and make sure they get wrapped in a session. The interceptor will not cover those since those requests will not get picked up by the spring DispatcherServlet.

Categories

Resources