Share the notes you took for yourself.
--Automatic retry if there is a high possibility that it has recovered in a few minutes ――In the first place, throttling in case of excessive communication If you use the cloud, you have to keep in mind automatic retries and throttling.
--When a failure occurs in the main system, it automatically changes to the secondary system.
CNAME switches after failover → Therefore, the application starts without permission.
The default is to cache DNS search results for the life of the JVM → So, even if the CNAME is switched, the JVM does not understand because of the cache "-Dnetowrkaddress.cache.ttl = 3" Set the number of seconds from the default -1
Spring Retry
AOP is slightly slower. It is easier and more reliable to use RetryTemplate explicitly.
application ↓ ← If this fails, retry up to XX times. It is also possible to retry the interval exponentially Connection pool ↓ JDBC driver ↓ DB
――Even if the failure on the other side of the cloud recovers in 90 seconds, your application that depends on it does not necessarily recover in 90 seconds. --There is no choice but to perform a failover test. --In the worst case, you don't have to retry (if the DBCP is set up properly).
Implemented framework migration to Spring a year ago. Migrated from Seasar, Struts, JSP.
Most of the work is rewriting the Controller and template.
Big difference
--How to pass data to view --How to receive the value in the Form class
Spring is messed up
For the time being, decide the rules of how to pass within the team If you create a Helper class in advance, it will be easier to unify.
Note that the Spring controller defaults to a singleton By using @Scope annotation, the timing of instantiation of controller class can be changed. (Default is singlton)
Precautions / Stumble points
--Note that getter / setter is required for Form class when binding Form with th: field and th: object. --If Spring Security is enabled, it will be 403 unless the csrf token is enabled → It will be solved by using th: action.
For Spring Security The Controller does not receive any parameters. Just define the required class as a bean.
Why it's hard to understand
――Because the process is hidden --Because authentication is firmly abstracted
--There are many implementation options → How to pass data to view, etc. --Many things to remember → Number of annotations, Spring Security, etc. ――The concealment of the framework is amazing → CSRF token, Spring Security, etc.
Then what should we do
--There are many implementation options → Common to all teams. Refer to other teams and products ――I often remember → I will do my best. Remember what you need each time ――The concealment of the framework is amazing → I will do my best.
--Spring subproject --Providing various security-related functions centered on authentication and authorization --The function is realized by multiple servlet filters.
Quite complicated among many products
Explanation based on the conventional servlet version Filters are managed as beans. logging.level.org.springframework.security = debug in application.properties Then you can check it in the log.
It's a good idea to read from the filter code.
Why use ThreadLocal Because the user information in the SecurityContext can be accessed from anywhere in the running thread
What the LogoutHandler is doing SecurityContextLogoutHandler is always executed last
What is Authentication Manager Interface for authentication processing
Spring Security is complicated, but code reading is fun
https://github.com/spring-projects/spring-security
Among the stories I heard, the story of the second person, Mr. Kinoshita, was very impressive because I could sympathize with it very often. Especially in summary
--Many implementation options ――I often remember --The hiding of the framework is amazing
Was very sympathetic.
Also, I had never heard of Spring Retry, and it was good to be able to recognize that Spring Security, which I felt was difficult, is also difficult for other people.
Recommended Posts