eclipes4j's 개발은 언제나 즐겁다.

'2018/07'에 해당되는 글 2건

  1. eclipse 에서 gradle querydsl 소스 생성시 dupulicate entry 문제
  2. JPA EhCache 사용.

eclipse 에서 gradle querydsl 소스 생성시 dupulicate entry 문제


eclipse 에서 gradle querydsl 소스 생성시 dupulicate entry 문제

뭐 딱히 generate task 를 만들지 않고 아래처럼 돌렸을 경우 eclipse에서는 정상적으로 생성된 클래스에 대한 classpath가 등록되는데,

querydsl {

    library = "com.querydsl:querydsl-apt:${querydslVersion}"



idea에서는 화면에 물려있는 classpath가 실제 build를 돌리면 generate-sources를 인식하지 못한다. 해서 intellij기준으로 맞추면 eclipse에서 중복된 classpath 등록 오류가..

여튼 작업자들이 idea를 사용하니 idea기준으로 작업환경을 유지해 주는 것으로 하기위해 eclipse 에 대한 glradle 로직을 추가했다.


eclipse.classpath.file {

  whenMerged { classpath ->

    def cpath = classpath.entries.findAll {

    entry -> entry.kind == 'src' && entry.output == 'bin/querydsl'


      classpath.entries.removeAll (cpath)



JPA EhCache 사용.

이전에는 redis나 memcached에 일반 엔티티들도 우걱우걱 밀어넣었는데, 네트웍 과부하 문제나 불필요한 트래픽 문제를 겪고 나서는 그냥 가벼운 엔티티 호출의 경우는 로컬 ehcache에서 읽어오도록 하고 있다.


@org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Goods {

  • Read-only: Useful for data that is read frequently but never updated (e.g. referential data like Countries). It is simple. It has the best performances of all (obviously).

  • Read/write: Desirable if your data needs to be updated. But it doesn't provide a SERIALIZABLE isolation level, phantom reads can occur (you may see at the end of a transaction something that wasn't there at the start). It has more overhead than read-only.

  • Nonstrict read/write: Alternatively, if it's unlikely two separate transaction threads could update the same object, you may use the nonstrict–read–write strategy. It has less overhead than read-write. This one is useful for data that are rarely updated.

  • Transactional: If you need a fully transactional cache. Only suitable in a JTA environment.