[issue]
개발 테스트 진행도중 config.properties 의 env.type이 dev임에도 불구하고 운영DB를 바라보는 페이지가 존재하였다.
운영 기준으로 데이터를 바라보는 DB는 2가지 타입이 있는데 이 2가지 타입을 개발DB에서는 병합하여 하나의 DB로 구분하고 있었고
마이그레이션 자체도 주기적으로 되지않고있어 개발하는 단계에서 대량의 데이터를 다루는 부분에만 운영을 바라보게 진행한 것으로 파악되었다.
확인해보니 공통으로 참조하고있는 CommonService 에서 아래의 모양새로 config.properties의 env.type과는 상관없이 하나의 context.properties를 바라보고있었다.
[CommonService]
@Resource
protected DataA dba;
@Resource
protected DataB dbb;
@Resource
protected UserDB userDb;
해당하는 daoimpl로 들어가면 아래의 형식으로 구분없이 부르고있는 모습을 확인할 수 있었다.
[DataAImpl]
@Inject
@Named("sqlSeesionDataA")
protected SqlSessionTemplate sqlSessionTemplate;
[DataBImpl]
@Inject
@Named("sqlSeesionDataB")
protected SqlSessionTemplate sqlSessionTemplate;
[UserDBImpl]
@Inject
@Named("sqlSeesionUserDB")
protected SqlSessionTemplate sqlSessionTemplate;
관련 bean을 찾아 확인해보니 아래와 같이 sqlSeesionOracleDataB을 바라보고있고 다른 xml 인 context-transcation을 바라보고있었다.
(솔직히 어차피 고정으로 둘건데 왜 이렇게 했는지는 의문이다...)
<bean id="sqlSeesionDataB">
<constructor-arg index="0" ref="sqlSeesionOracleDataB"></constructor>
<constructor-arg index="1" ref="BATCH"></constructor>
</bean>
<bean id="sqlSeesionOracleDataB">
<property name="dataSource" ref="dataSourceOracle"/>
<property name="configLocation" value="classpath:sql/mybatis/oracle/mybatis-config.xml"/>
</bean>
드디어 찾은 파일에서는
<bean id="dataSourceOracle" class="" destroy-method="close">
<property name="driverClassName" value="#{contextProperties.driver}"/>
<property name="url" value="#{contextProperties.url}"
<property name="username" value="#{contextProperties.username}"
<property name="password" value="#{contextProperties.password}"
<property name="autoCommit" value="false"/>
....</bean>
역시나 고정파일로 되어있었고 그러면 운영은 어떻게 구분하나 확인을 해봤더니 배포툴에서 사용하는 빌드파일에서
war로 압축시킬때만 config.properties의 env.type에 따라서 context-dev.properties, context-real.properties 로 교체해주고 있었다.
결론은 로컬에서 테스트하는 개발자만 알아서 context.properties의 url,username,password등을 수동으로 바꿔주지 않으면 안되는 구조였다.
이 프로젝트를 개발하신분도 이제와서 분기치기엔 영향도 조사를 해야하니 그냥 운영,개발 주석처리하고 바꾸라는 피드백을 받았다.
차후에 DB의 분리를 개발과 운영이 같은 모양새로 데이터 A,B를 분리하게되면 어차피 나중에는 대참사가 날 것이다.
인터셉터라는 기능을 활용하여 전처리 과정을 진행하던가 지금 사용하고있는 common을 어차피 다 호출하고 있으니 이부분에서 수정을보던가 해야할거같다는 생각에
일단 두개의 방식을 구현하고 부장님한테 선택을 맡길예정이다..
시닙잔디쟁이는 왠지 재밌는 업무가 생겨 신이난다 까르르..
'개발일지✏️' 카테고리의 다른 글
[운영] 로그 수집시 시간차 이슈 (TimeBaseRollingPolicy 이자식..) (0) | 2024.03.13 |
---|