Skip to main content

Home/ SoftwareEngineering/ Group items matching "import" in title, tags, annotations or url

Group items matching
in title, tags, annotations or url

Sort By: Relevance | Date Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

Article Series: Migrating Spring Applications to Java EE 6 - Part 1 | How to JBoss - 1 views

  • In fact people still love those books without realizing that the world has changed dramatically ever since
  • The reality check here is to wonder whether the rhetorics set forth by Rod Johnson in his 2003/2004 books are still actual today
  • So if you still care about those books, the best way to show your appreciation is probably to use them as your monitor stand
  • ...21 more annotations...
  • The discussion whether or not to use Spring vs. Java EE for new enterprise Java applications is a no-brainer
  • Why migrate?
  • since then fallen a prey to the hungry minds of Venture Capitalists and finally into the hands of a virtualization company called VMware
  • While the different companies and individuals behind the Spring framework have been doing some work in the JCP their voting behavior on important JSRs is peculiar to say the least
  • outdated ORM solution like JDBC templates
  • some developers completely stopped looking at new developments in the Java EE space and might have lost track of the current state of technology
  • size of the deployment archive
  • fairly standard Java EE 6 application will take up about 100 kilobytes
  • comparable Spring application weighs in at a whopping 30 Megabytes!
  • Lightweight
  • Firing up the latest JBoss AS 7 Application Server from scratch and deploying a full blown Java EE 6 application into the server takes somewhere between two and five seconds on a standard machine. This is in the same league as a Tomcat / Spring combo
  • Dependency injection
  • Java EE 6, the Context and Dependency Injection (CDI) specification was introduced to the Java platform, which has a very powerful contextual DI model adding extensibility of injectable enterprise services
  • Aspect Oriented Programming
  • “AOP Light” and this is exactly what Java EE Interceptors do
  • common pitfall when taking AOP too far is that your code might end up all asymmetric and unreadable. This is due to the fact that the aspect and its implementation are not in the same place. Determining what a piece of code will do at runtime at a glance will be really hard
  • Testing
  • With Arquillian we can get rid of mocking frameworks and test Java EE components in their natural environment
  • Tooling
  • capabilities comparison matrix below to map Spring’s technology to that of Java EE
  • Capability Spring JavaEE Dependency Injection Spring Container CDI Transactions AOP / annotations EJB Web framework Spring Web MVC JSF AOP AspectJ (limited to Spring beans) Interceptors Messaging JMS JMS / CDI Data Access JDBC templates / other ORM / JPA JPA RESTful Web Services Spring Web MVC (3.0) JAX-RS Integration testing Spring Test framework Arquillian *
kuni katsuya

MySQL :: MySQL 5.7 Reference Manual :: 5.4.4.2 Configurable InnoDB Auto-Increment Locking - 0 views

  • Configurable
    • kuni katsuya
       
      new and improved!(?)
  • table-level locks held until the end of a statement make INSERT statements using auto-increment safe for use with
  • statement-based replication
  • ...24 more annotations...
  • However, those locks limit concurrency and scalability when multiple transactions are executing insert statements at the same time
  • For INSERT statements where the number of rows to be inserted is known at the beginning of processing the statement, InnoDB quickly allocates the required number of auto-increment values without taking any lock, but only if there is no concurrent session already holding the table-level AUTO-INC lock (because that other statement will be allocating auto-increment values one-by-one as it proceeds)
  • obtains auto-increment values under the control of a mutex (a light-weight lock) that is not held until the statement completes, but only for the duration of the allocation process
  • innodb_autoinc_lock_mode = 0 (“traditional” lock mode)
  • special table-level AUTO-INC lock is obtained and held to the end of the statement
  • lock mode is provided for:
  • Backward compatibility.
  • innodb_autoinc_lock_mode = 1 (“consecutive” lock mode)
  • important impact of this lock mode is significantly better scalability
  • This mode is safe for use with
  • statement-based replication
  • innodb_autoinc_lock_mode = 2 (“interleaved” lock mode)
  • This is the fastest and most scalable lock mode
  • but it is
  • not safe
  • when using
  • statement-based replication
  • recovery scenarios when SQL statements are replayed from the binary log
  • Using auto-increment with replication
  • set innodb_autoinc_lock_mode to 0 or 1 and use the same value on the master and its slaves
  • Auto-increment values are not ensured to be the same on the slaves as on the master if you use innodb_autoinc_lock_mode = 2 (“interleaved”) or configurations where the master and slaves do not use the same lock mode
  • If you are using
  • row-based replication
  • all of the auto-increment lock modes are safe
kuni katsuya

Chapter 15. Data Management - 1 views

  •  abstractEntity.uid();
    • kuni katsuya
       
      sets the uid before persist
  •  UUID.randomUUID().toString();
  • AbstractEntity 
  • ...70 more annotations...
  • @MappedSuperclass
  • Important things on ID/UID
  • entity lives in three layers:
  • Flex client
  • JPA persistence context
  • database
  • When updating existing entities coming from the database
  • id is defined and is maintained in the three layers during the different serialization/persistence operations
  • when a new entity is being created in any of the two upper layers (Flex/JPA)
  • new entity has no id until it has been persisted to the database
  • most common solution is to
  • have a second persisted id, the uid
  • which is created by the client and persisted along with the entity
  • recommended approach to avoid any kind of subtle problems is to have a real uid property which will be persisted in the database but is not a primary key for efficiency concerns
  • You can now ask Tide to
  • limit the object graph before sending it
  • Flex with the following API :
  • EntityGraphUnintializer
  • uninitializeEntityGraph
  • Person object will be uninitialized
  • uperson contains
  • only the minimum of data
  • to correctly merge your changes in the server persistence context
  • Tide uses the
  • client data tracking
  • to determine which parts of the graph need to be sent
  • Calling the EntityGraphUninitializer manually is a bit tedious and ugly, so there is a cleaner possibility when you are using generated typesafe service proxies
  • annotate your service method arguments with @org.granite.tide.data.Lazy :
  • @Lazy
  • take care that you have added the [Lazy] annotation to your Flex metadata compilation configuration
  • in the Flex application, register the UninitializeArgumentPreprocessor component in Tide as follows :
  • [UninitializeArgumentPreprocessor]
  • all calls to PersonService.save() will
  • automatically use a properly uninitialized version
  • of the person argument.
  • 15.4. Dirty Checking and Conflict Handling
  • simplify the handling of data between Flex and Java EE
  • Chapter 15. Data Management
  • Tide maintains a client-side cache of entity instances and ensures that every instance is unique in the Flex client context
  •  uid().hashCode();
  • Tide currently only supports Integer or Long version fields, not timestamps and that the field must be nullable
  • in a multi-tier environment (@Version annotation)
  • highly recommended to use
  • JPA optimistic locking
  • highly recommended to add a
  • persistent uid field
  • AbstractEntity
  • in general this identifier will be
  • initialized from Flex
  • @Column(name="ENTITY_UID", unique=true, nullable=false, updatable=false, length=36)     private String uid;
  • @Version     private Integer version;
  • uid().equals(((AbstractEntity)o).uid())
  • consistent identifier through all application layers
  • @PrePersist
  • 15.3. Reverse Lazy Loading
  • 15.4. Dirty Checking and Conflict Handling
  • 15.4. Dirty Checking and Conflict Handling
  • 15.4. Dirty Checking and Conflict Handling
  • Dirty Checking and Conflict Handling
  • entity instance can be in two states :
  • Stable
  • Dirty
  • property meta_dirty is
  • bindable
  • could be used
  • to enable/disable a Save button
  • correct way of knowing if any object has been changed in the context, is to use the property meta_dirty of the Tide context
  • tideContext.meta_dirty
  • reliable when using optimistic locking
  • check that its @Version field has been incremented
‹ Previous 21 - 23 of 23
Showing 20 items per page