블로그 이미지
GUCCI

카테고리

전체보기 (111)
여행 (1)
기기 (2)
쇼핑 (0)
게임 (0)
etc. (6)
취업이야기 (0)
업무일지 (5)
리눅스 (38)
웹프로그래밍 (2)
네트워크 (4)
JAVA (17)
Android (0)
IOS (2)
LUA (8)
C/C++ (1)
Objective C (2)
SERVER (2)
그누보드4 (1)
MSSQL (2)
Programming (1)
자바스크립트 (4)
HTML/CSS (1)
LGNAS (0)
Total
Today
Yesterday

IOS8 SDK 알림설정

IOS / 2015. 1. 19. 15:52

앱을 구현하다가 보면 시스템 알림 설정값을 체크해야 하는 경우들이 있다.

일반적으로 iOS8 이전 SDK 에서는 아래와 같은 방법으로 체크를 하였지만,

1
2
3
4
5
6
7
8
if([UIApplication sharedApplication].enabledRemoteNotificationTypes  == UIRemoteNotificationTypeNone) {
    // 시스템 알림 설정이 꺼져있는 경우
}
else {
    // 시스템 알림 설정이 켜져있는 경우.
    // UIRemoteNotificationTypeBadge, UIRemoteNotificationTypeSound, UIRemoteNotificationTypeAlert, UIRemoteNotificationTypeNewsstandContentAvailability
    // 위의 네가지 경우에 만족하는 상태
}


iOS8 SDK 부터는 enabledRemoteNotificationTypes 이 메서드가 Deprecated 되어 사용할 수 없게 되었다.


이 문제를 수정하기 위해서는 iOS8과 그 이하 버전의 분기를 타야 하고, 변경된 메서드를 아래와 같이 적용해 주어야 한다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
if ([[UIDevice currentDevice].systemVersion characterAtIndex:0] >= '8') {
    if([UIApplication sharedApplication].currentUserNotificationSettings.types  == UIUserNotificationTypeNone){
    // 시스템 알림 설정이 꺼져있는 경우
    }
    else {
        // 시스템 알림 설정이 켜져있는 경우.
        // UIUserNotificationTypeBadge, UIUserNotificationTypeSound, UIUserNotificationTypeAlert
        // 위의 세가지 경우에 만족하는 상태
    }
}
else {
    if([UIApplication sharedApplication].enabledRemoteNotificationTypes  == UIRemoteNotificationTypeNone){
        // 시스템 알림 설정이 꺼져있는 경우
    }
    else {
        // 시스템 알림 설정이 켜져있는 경우.
        // UIRemoteNotificationTypeBadge, UIRemoteNotificationTypeSound, UIRemoteNotificationTypeAlert, UIRemoteNotificationTypeNewsstandContentAvailability
        // 위의 네가지 경우에 만족하는 상태
    }
}


이 문제는 새로운 버전으로 작업을 하면서 크래쉬같이 눈에 보여서 바로 수정할 수 있는 이슈가 아니라 놓치기 쉬운 문제이니 잘 확인해야 할 것 같다.

'IOS' 카테고리의 다른 글

맥북 구입 점검 사항  (4) 2012.03.22
Posted by GUCCI
, |

WLS9.2 이상의 JDBC Connection leak profiling

문제.

Oracle WebLogic Server JDBC Connection Leak 여부를 감지하고애플리케이션에서 leak connection 유발하는 stacktrace log 출력하며, auto close해주는 기능을 가지고 있다.

 기능을 수행하는 옵션이 기존 버전(WLS8.x 이하) 달리 WLS9.x부터 Diagnostic framework 개념이도입되면서 수정되었다.

 

우선은, WLS에서 말하는 “Automatically Recovering Leaked Connections” 개념과 WLS8.x 비교하여WLS9.x이상부터 설정하는 방법에 대해 알아본다.

 

WLS8.x VS WLS9.x의 설정 방법.

1. WLS8.x 설정 방법.

Services -> JDBC-> Connection Pools -> 설정할 Connection Pool 이름 -> Connections tab -> Enable Connection Leak Profiling 체크2. WLS9.x이후 버전 설정 방법.

1) Profile Connection Leak

많은 사용자들이 혼돈하는 사항이다실제 위의 옵션의 의미는 다음과 같다해당 옵션은 data source로부터 획득한 connection 보유하고 있는 Thread connection leaked 정보를 수집한다 옵션을 통해서는 leaked connection Connection Pool 반환되는 것이 아니라 leaked connection 정보를 수집하여 Diagnostic Data 사용하거나 WLS log 파일에 출력하는데 사용된다.

2) Inactive Connection Timeout

JDBC Leaked Connection datasource Connection Pool 정상적으로 반환되지 않는 Connection의미한다. - 이러한 Leaked Connection 자동으로 회수하기 위해서는사용자는 관리 콘솔의 “JDBC Data Source>Configuration>Connection Pool” 페이지에서 “Inactive Connection Timeout” 속성을 정의해야 한다해당 옵션의 값이 설정되면, WebLogic Server 사용자가 정의한 시간 동안 Reserved Connection 아무런 활동이 없는 경우 data source 해당 connection 강제적으로 반환해 준다 옵션의 기본값은 “0”이며 값의 의미는 해당 기능이 OFF상태임을 의미한다.

 

추가적으로만일 사용자 프로그램에서 모든 statement 문을 close 하고 connection  닫지 않은 경우connection leak  detect되지 않을 것이다 문제는 WLS9.1~WLS10.0MP1에서만 발생하여 이를 해결하기 위해서는 CR314547패치를 적용해야 한다해당 패치에 대한 상세 내용은 아래를 참조하라.

 

CR314547 - WLS 9.2 MP1 - JDBC connection leak not detected 
- DIAGNOSIS:
In the wrapper Statement internalClose()method we mistakenly nullify the local variable conn so that we can't set the connection not-in-use in the postInvoke() method after JDBC call has competed. The connection will be thought in the middle of call forever and the pool will never retract it therefor connection leaking happens.
- RESOLUTION:
Now we do not nullify conn in the internalClose()method of Statement
- RELEASE NOTE:
Now JDBC connection leak will be detected if all statements are closed but the connection is not released.

 

 




WLS9.x
에서 leak connection  recovering   나타나는 로그 파일에 추가되는 내용이다.
, leak 이라고 판단되는 Connection "Inactive Connection Timeout" 설정된  이후 자동으로 회수할 아래의 내용이 로그에 출력될 것이다사용자는 해당 로그를 통해 잘못된 로직을 수정해야 한다.

<2009. 9. 24 오후 7 21 22 ACT> <Warning> <JDBC> <BEA-001153> <Forcibly releasinginactive conn
ection "[weblogic.jdbc.wrapper.JTAConnection_weblogic_jdbc_wrapper_XAConnection_oracle_jdbc_driver_L
ogicalConnection-ora920DS-1, oracle.jdbc.driver.LogicalConnection@1f36af6]" back into the connection
pool "ora920DS", currently reserved by: java.lang.Exception

 

 

참고 자료.





WAS에 배포된 애플리케이션들이 DB작업을 하는데 있어서 WAS 제품에 의해 제공된 커넥션 풀의 상황에 대한 모니터링을 해준다.

웹로직 서버에 배포된 애플리케이션들은 제공되는 Data Source를 가지고 DB에 접근하게된다.

Data Source는 커넥션 풀을 가지고 있으며, ....


==============================================================================
다양한 문제 사례
==============================================================================
1. 특정 서버에 대한 cpu 사용률이 다른 서버에 비해 월등히 높다. (모든 서버가 동일 업무처리)
접근키워드: 특정 서버, cpu 사용률
특정 서버가 문제가 되는것은 WAS 앞단에서 전달을 잘못했다.
cpu 사용률이 높아지는 업무에는 DB, ...등이 있다.

2. 쓰레드는 놀고있는데 현재 사용중인 DB connection은 너무 많다.
접근키워드: 
쓰레드가 놀고있다. -> 부하는 그리 많지 않다. 또는 부하가 있더라도 처리가 빨리되서 쓰레드가 빨리 반납된다.
DB connection이 너무 많다. -> 실제 DB업무가 많다. 또는 쓰지도 않으면서 커넥션만 맺어져있다.








관리자는 Data Source에 대한 모니터링을 통해 뭘 할 수 있을까?

쓰레드와 Data Source 모니터링을 통해 쓰레드와 커넥션의 개수를 산정한다.

connection leak이 발생하는 것을 추측할 수 있다.

쓰레드는 놀고 있는데, connection 사용량이 생각보다 많다면 connection leak을 예상할 수 있다.

정확하게 connection leak 여부를 판단하기 위해서는 다음의 두가지가 필요하다.

inactive connection timeout값 설정 
profiling connection leak 옵션 enable

만약 connection leak이 발생하면 weblogic server log에 connection leak이 감지되었음을 알리는 로그가 남게된다.

Data Source와 Data Source를 사용하는 서버 인스턴스별로 아래 항목이 각각 보여지게 된다.

동일한 Data Source에서 Active Connections Average Count가 특별하게 높은 서버 인스턴스에 대해서
해당 서버가 해당 DS(Data Source)를 처리하는 업무가 많다. (DB 접근 업무가 많다)
만약 3대의 서버가 동일 업무를 처리하는데 특정 서버의 Active Connections Average Count가 높다면,
앞단의 L4, 웹서버등의 로드밸런서(부하분산기)가 부하분산을 제대로 못했거나 재수없게 DB 업무가 해당 서버에 몰린다고 볼 수 있다.




DataSource 모니터링 화면의 항목자료형한글 설명
Server  고정값DataSource가 배포되어 있는 Server명
Active Connections Average Count 기동후 누적값기동 후부터 조회한 시점까지의 Active Connection의 평균값
- Avg(Active Connections Current Count)
Active Connections Current Count 현재 조회값현재 사용 중인 Connection 개수
Active Connections High Count 기동후 최대값기동 후부터 조회한 시점까지의 Active Connection의 최대값
- Max(Active Connection Current Count)
Connection Delay Time 기동후 누적값millisecond 단위로 DB와의 물리적인 연결하는데 걸린 평균 시간값
- Avg(DB Connection 연결 시간들)
Connections Total Count 기동후 누적값기동 후부터 조회한 시점까지의 DB Connection이 생성된 총횟수
- Sum(Create DB Connection)
Current Capacity 현재 조회값현재 연결되어 있는 DB Connection 개수
Curr Capacity High Count 기동후 최대값기동 후부터 조회한 시점까지의 Current Capacity의 최대값
- Max(Current Capacity)
Enabled 고정값DataSource의 Enabled/Disabled의 상태
Failed Reserve Request Count 기동후 누적값해당 DS에서 요청을 받았지만 수행되지 못한 누적 수
Failures To Reconnect Count 기동후 누적값해당 DS가 DB Connection refresh를 시도해서 실패한 수. DB가 unavailable 이거나 DB로의 network connection이 원활하지 않은 경우 refresh가 실패할 수 있음
Highest Num Available 기동후 최대값기동 후부터 조회한 시점까지의 Num Available의 최대값
- Max(Num Available)
Leaked Connection Count 현재 조회값close()하지 않은 누수된 Connection 개수
Num Available 현재 조회값현재 사용할 수 있는 DataSource 개수
Num Unavailable 현재 조회값현재 사용할 수 없는 DataSource 개수
PrepStmt Cache Access Count 기동후 누적값기동 후부터 조회한 시점까지의 Statement Cache에 Access한 총횟수로 각 Connection마다의 Access한 횟수의 총합계
Prep Stmt Cache Add Count 기동후 누적값기동 후부터 조회한 시점까지의 Statement Cache에 Add한 총횟수로 각 Connection 마다의 Add한 횟수의 총합계
Prep Stmt Cache Current Size 현재 조회값기동 후부터 조회한 시점까지의 각 Connection의 Statement Cache의 크기의 총합계
Prep Stmt Cache Delete Count 기동후 누적값기동 후부터 조회한 시점까지의 Statement Cache에 Delete한 총횟수로 각 Connection 마다의 Delete한 횟수의 총합계
- Statement Cache가 full 상태에서 새로운 Statement를 Add하려고 할 때 Statement Cache Delete가 발생함
Prep Stmt Cache Hit Count 기동후 누적값기동 후부터 조회한 시점까지의 Statement Cache의 해당 Statement가 있었던 총횟수
Prep Stmt Cache Miss Count 기동후 누적값기동 후부터 조회한 시점까지의 Statement Cache의 해당 Statement가 없었던 총횟수
Reserve Request Count 기동후 누적값Connection을 요청한 총 횟수
State 현재 조회값DataSource의 상태 : Running/Suspended/Shutdown/Unhealthy/Unknown
JDBC Driver 고정값JDBC Driver명
Wait Seconds High Count 기동후 누적값connection 을 얻기 위해 가장 오래 기다린 시간
Waiting For Connection Current Count 현재 조회값현재 Connection을 얻기 위해서 기다리고 있는 개수
Waiting For Connection Failure Total 기동후 누적값기동 후부터 조회한 시점까지의 Connection을 받기 위해서 기다렸으나 Connection을 얻지 못한 횟수의 총합계
- Sum
Waiting For Connection High Count 기동후 최대값기동 후부터 조회한 시점까지의 Connection을 받기 위해서 기다렸던 횟수의 최대값
- Max(Waiting For Connection Current Count)
Waiting For Connection Success Total 기동후 누적값기동 후부터 조회한 시점까지의 Connection을 받기 위해서 기다리고 성공적으로 Connection을 얻은 횟수의 총합계
Waiting For Connection Total 기동후 누적값기동 후부터 조회한 시점까지의 Connection을 받기 위해서 기다렸던 횟수의 총합계



기능설명

 

JDBC Connection Pool Leak - Stack Trace 설정 옵션

 

Version

설정항목

기능

Weblogic 8.x

1) Enable Connection Leak Profiling

-   Leak Message & Stack Trace 생성

-    설정시간 초과되는 JDBC Pool 회수(idle 상태로 회수)

-   Weblogic 서버로그에 생성

Weblogic 9 higher

1)  Profile Connection Leak

2)  Inactive Connection Timeout

 

-  Weblogic 9.0 이후부터 Profile Connection Leak + Inactive Connection Timeout 까지같이 설정할 경우 Inactive connection Timeout시간이 되면 서버로그에 stack trace 내용까지 표시된  JDBC Connection Pool 회수 .

-  Weblogic 8.x 까지는 Enable Connection Leak Profiling 설정함.

 적용하여 검증된 사항으로시스템 성능에 영향을 주지 않으므로 구성  적용하는 것을 권고

 

옵션특징

옵션

특이사항

< Weblogic 8.x >

Enable Connection Leak Profiling

 

< Weblogic 9 higher >

Profile Connection Leak

 

< Weblogic 9 higher >

-     옵션만 설정  Leak Message  생성

< Weblogic 9 higher >

Inactive Connection Timeout

-    Stack trace 까지 보기위해 설정필요

-    설정  application 처리시간을 확인하여 적용필요

, JDBC 업무처리 시간이 최대 120초이고 초과  비정상으로 판단되면 120 ~ 121 수치적용

 

 

Weblogic 10 Version  따라 Inactive Connection Timeout 설정  JDBC Driver 따라 다음과 같이 메시지가 표시된다

Weblogic Version

XA Driver

Non-XA Driver

9.x 이상

Warning 경고만 발생

메시지가 표시 되지 않을  System.out추가

서버로그 확인

-  XA Driver  경우 메시지가 표시되지 않는 경우가 있으며 이러한 경우 소스 Exception 부분에 System.out.println 부분을 추가하여 확인할  있다.

-  Non-XA Driver  경우 메시지 표시가 된다.


 

 

설정방법

 

 

 Profile Connection Leak

 

Weblogic Console --> Services --> Data Sources --> 해당 Data Source 선택 -->

Configuration --> Diagnostics -->

 

 

 

 

 Inactive Connection Timeout

 

Weblogic Console --> Services --> Data Sources --> 해당 Data Source 선택 -->

Configuration --> Connection Pool --> Advanced

 

 

 

 

 


 

로그예시

 

 

Non-XA dirver Stack 표시

<2011. 4. 11 오전 8 16 16 KST> <Warning> <JDBC> <BEA-001153> <Forcibly rel

easing inactive connection "weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_dri

ver_T4CConnection@2d" back into the connection pool "jdbcDS", currently reserved

 by: java.lang.Exception

        at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.java:318)

        at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:344)

        at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:322)

        at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:438)

        at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:317)

        at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:93)

        at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:106)

        at weblogic.jdbc.pool.Driver.connect(Driver.java:149)

        at weblogic.jdbc.jts.Driver.getNonTxConnection(Driver.java:652)

        at weblogic.jdbc.jts.Driver.connect(Driver.java:127)

        at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:355)

        at jsp_servlet.__test_noxa._jspService(__test_noxa.java:96)

        …

at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)

        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)

        …

        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)

at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1446)

        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)

        at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

.>

 

 

 

XA dirver 사용  Stack  안보이는 일부경우(보일때도 있으며 안보이는 경우도 있다.)

<2011. 4. 11 오후 1 40 23 KST> <Warning> <Common> <BEA-000620> <Forcibly r

eleasing inactive resource "autoCommit=true,enabled=true,isXA=true,isJTS=false,v

endorID=0,connUsed=false,doInit=false,'null',destroyed=false,poolname=jdbcXADS,a

ppname=null,moduleName=null,connectTime=32,dirtyIsolationLevel=false,initialIsol

ationLevel=2,infected=false,lastSuccessfulConnectionUse=1302496634640,secondsToT

rustAnIdlePoolConnection=10,currentUser=null,currentThread=null,lastUser=null,cu

rrentError=null,currentErrorTimestamp=null,JDBC4Runtime=true,supportStatementPoo

lable=true,needRestoreClientInfo=false,defaultClientInfo={},supportIsValid=true"

 back into the pool "jdbcXADS".>

 

Source 상에 Exception 부분에 System.out.println 부분을 추가하여Stack 표시

java.sql.SQLException: Internal error: Cannot obtain XAConnection weblogic.commo

n.resourcepool.ResourceLimitException: No resources currently available in pool

jdbcXADS to allocate to applications, please increase the size of the pool and r

etry..

        at weblogic.common.resourcepool.ResourcePoolImpl.reserveResourceInternal

(ResourcePoolImpl.java:577)

        at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:342)

        at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:419)

        at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:324)

        at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:94)

        at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:63)

        at weblogic.jdbc.jta.DataSource.getXAConnectionFromPool(DataSource.java:1677)

        at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1445)

        at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:446)

        at weblogic.jdbc.jta.DataSource.connect(DataSource.java:403)

        at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:364)

        at jsp_servlet.__test_xa._jspService(__test_xa.java:101)

        at weblogic.servlet.jsp.JspBase.service(JspBase.java:34)

        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)

        ….

        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)

        at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)

        at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)

        at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)

        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)

        at weblogic.work.ExecuteThread.run(ExecuteThread.java:176)

 

<2011. 4. 11 오후 2 19 11 KST> <Warning> <Common> <BEA-000620> <Forcibly r

eleasing inactive resource "autoCommit=true,enabled=true,isXA=true,isJTS=false,v

endorID=0,connUsed=false,doInit=false,'null',destroyed=false,poolname=jdbcXADS,a

ppname=null,moduleName=null,connectTime=47,dirtyIsolationLevel=false,initialIsol

ationLevel=2,infected=false,lastSuccessfulConnectionUse=1302499081281,secondsToT

rustAnIdlePoolConnection=10,currentUser=java.lang.Exception

        at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.java:310)

        at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:344)

        at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:322)

        at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:431)

        at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:316)

        at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:93)

        at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:61)

        at weblogic.jdbc.jta.DataSource.getXAConnectionFromPool(DataSource.java:1584)

at weblogic.jdbc.wrapper.Statement.close(Statement.java:390)

        at jsp_servlet.__test_xa._jspService(__test_xa.java:120)

        at weblogic.servlet.jsp.JspBase.service(JspBase.java:34)

        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)

        at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)

        …

at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)

        at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202)

        at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108)

        at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432)

        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)

        at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

,currentThread=null,lastUser=null,currentError=null,currentErrorTimestamp=null,J

DBC4Runtime=true,supportStatementPoolable=true,needRestoreClientInfo=false,defau

ltClientInfo={},supportIsValid=true" back into the pool "jdbcXADS".>

저작자 표시 비영리 변경 금지


Posted by GUCCI
, |
문제 설명
응용 프로그램 또는 WebLogic Server 자체에 사용되는 JDBC 커넥션에 의해 해당 커넥션을 통한 호출이 완료될 때까지 WebLogic Server Execute 스레드가 차단됩니다. JVM은 CPU가 자체적인 스레드 스케줄 메커니즘에 따라 실행 가능한 스레드에 할당되며 SQL 쿼리를 차단하는 스레드가 대기해야 하는지 확인합니다. 그러나 JDBC가 사용 중인 스레드는 SQL 쿼리에서 호출이 반환될 때까지 응용 프로그램용으로 할당됩니다.

트랜잭션 시간이 초과되더라도 해당 트랜잭션에 참가한 리소스가 수행하는 작업이 중단되거나 종료되지 않습니다. 작업은 진행되는 동안 중단 없이 실행됩니다. 트랜잭션 제한 시간에 따라 설정된 플래그에 의해 트랜잭션이 롤백만 가능한 것으로 표시되기 때문에 이 트랜잭션에 대한 이후의 모든 커밋 요청은 TimedOutException 또는 RollbackException이 발생하여 실패합니다. 그러나 위에서 언급한 것처럼 실행 시간이 긴 JDBC 호출로 인해 WebLogic Server Execute 스레드가 차단될 수 있으며 그 결과 모든 스레드가 차단되어 들어오는 요청을 처리할 Execute 스레드가 남지 않으면 인스턴스가 Hang(정지) 상태가 될 수 있습니다.

최신 버전의 WebLogic Server에서는 스레드가 특정 시간(디폴트값: 600초) 내에 반응하지 않는지 규칙적으로 확인하는 상태 검사 기능이 제공됩니다. 이러한 문제가 발생하면 로그 파일에 다음과 같은 오류 메시지가 출력됩니다.


####<Nov 6, 2004 1:42:30 PM EST> <Warning> <WebLogicServer> <mydomain> <myserver> <CoreHealthMonitor> <kernel identity> <> 
<000337> <ExecuteThread: '64' for queue: 'default' has been busy for "740" seconds working on the request "Scheduled Trigger", 
which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>


이 오류 메시지는 단순히 관리자에게 상태를 알리기 위한 것으로 스레드가 중단되지는 않습니다. 멈춘 스레드는 요청 처리가 완료되어야 다시 실행됩니다. 이 경우 WebLogic Server의 로그 파일에 다음과 같은 메시지가 표시됩니다.


####<Nov 7, 2004 4:17:34 PM EST> <Info> <WebLogicServer><mydomain> <myserver> <ExecuteThread: '66' for queue: 'default'>
<kernel identity> <> <000339> <ExecuteThread: '66' for queue: 'default' has become "unstuck".>


상태 검사 기능의 간격은 변경할 수 있습니다. config.xml 파일의 <Server> 태그에서 StuckThreadMaxTime 속성을 확인하십시오. 자세한 내용은 http://e-docs.bea.com/wls/docs81/config_xml/Server.html#StuckThreadMaxTime 또는 http://e-docs.bea.com/wls/docs81/perform/WLSTuning.html#stuckthread의 WebLogic Server 관리 콘솔 도움말에서 "멈춘 스레드 검색" 단원을 참조하십시오.

페이지 맨 위

문제 해결
다른 프로그래밍 방법이나 JDBC 커넥션 풀 구성을 사용할 경우 JDBC 데드락(Deaklock) 또는 WebLogic Server 인스턴스 Hang(정지) 상태를 초래하는 JDBC 호출이 발생할 수 있습니다. WebLogic Server 인스턴스 Hang(정지) 상태를 해결하고 분석하는 방법에 대한 자세한 내용은 일반적인 서버 Hang(정지) 패턴을 참조하십시오.

이 패턴에서는 서버 Hang(정지) 상태의 원인이 되는 JDBC 호출과 기타 WebLogic Server 인스턴스 Hang(정지) 상태를 초래하는 일반적인 JDBC 관련 문제에 대해 설명합니다. 이 패턴의 참조 지원 패턴은 WebLogic Server 지원 패턴 사이트에서 확인할 수 있습니다.

항목 바로가기

문제 발생 원인
다음과 같은 경우 WebLogic Server 인스턴스 Hang(정지) 상태가 발생할 수 있습니다.
  • JDBC 코드에 DriverManager.getConnection()을 사용하는 경우
  • 데이터베이스에 대한 SQL 쿼리 결과가 반환되는 데 너무 오래 걸리는 경우
  • JDBC 커넥션 풀이 구성된 데이터베이스가 Hang(정지)되어 적절한 시간 내에 호출에 응답하지 않는 경우
  • 느리거나 오버헤드가 발생한 네트워크로 인해 데이터베이스 호출이 느려지거나 Hang(정지)되는 경우
  • 데드락으로 인해 모든 Execute 스레드가 Hang(정지)되어 계속 대기하는 경우
  • JDBC 커넥션 풀의 RefreshMinutes 또는 TestFrequencySeconds 속성으로 인해 WebLogic Server에서 Hang(정지) 기간이 발생하는 경우
  • JDBC 커넥션 풀 축소 및 데이터베이스 커넥션 재생성으로 인해 응답 시간이 길어지는 경우
페이지 맨 위

동기화된 DriverManager.getConnection()
이전의 JDBC 응용 프로그램 코드에서는 특정 드라이버를 사용하는 데이터베이스 커넥션을 검색하기 위해DriverManager.getConnection() 호출을 사용하기도 했습니다. 이 방법은 데드락을 발생시키거나 커넥션 요청의 성능을 상대적으로 저하시킬 수 있으므로 사용하지 않는 것이 좋습니다. 이러한 문제가 발생하는 원인은 모든 DriverManager 호출이 클래스별로 동기화되어 있어 한 스레드의 특정 DriverManager 호출이 WebLogic Server 인스턴스의 스레드에서 발생하는 다른 모든 DriverManager 호출을 차단하기 때문입니다.

또한 SQLException 생성자에 의해 DriverManager 호출을 발생시키는 대부분의 드라이버에는 로깅을 위한DriverManager.println() 호출이 포함되어 있기 때문에 DriverManager 호출을 보내는 다른 모든 스레드가 차단될 수 있습니다.

DriverManager.getConnection()에 의해 데이터베이스에 대해 만들어진 커넥션이 반환될 때까지는 상당히 오래 걸립니다. 데드락이 발생하지 않더라도 한 스레드가 커넥션을 가져올 때까지 다른 모든 호출은 대기해야 합니다. WebLogic Server와 같은 멀티 스레드 시스템의 경우 이러한 방법은 바람직하지 않습니다.


이 정보는 http://forums.bea.com/bea//thread.jspa?forumID=2022&threadID=200063365&messageID=202311284&start=-1#202311284에서 발췌한 내용입니다.
DriverManager.getConnection()을 사용해서는 안 된다는 점은 http://e-docs.bea.com/wls/docs81/faq/jdbc.html#501044의 설명서에도 명확히 기술되어 있습니다.

JDBC 코드에 JDBC 커넥션을 사용하려면 WebLogic Server JDBC 커넥션 풀을 사용하고 풀에 대한 DataSource를 정의하여 DataSource에서 커넥션을 가져와야 합니다. 그러면 데이터베이스가 다운되는 등의 문제가 발생한 경우에 리소스 공유, 커넥션 재사용, 커넥션 새로 고침과 같은 풀의 이점을 활용할 수 있습니다. 또한 DriverManager 호출 시에 데드락 발생을 방지할 수 있습니다. WebLogic Server에서 JDBC 커넥션 풀, DataSource 및 기타 JDBC 개체를 사용하는 방법에 대한 자세한 내용은http://e-docs.bea.com/wls/docs81/jdbc/intro.html#1036718 및 http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1054307을 참조하십시오.

DriverManager.getConnection() 호출에서 차단된 스레드의 일반적인 유형은 다음과 같습니다.
"ExecuteThread-39" daemon prio=5 tid=0x401660 nid=0x33 waiting for monitor entry [0xd247f000..0xd247fc68]
  at java.sql.DriverManager.getConnection(DriverManager.java:188)
  at com.bla.updateDataInDatabase(MyClass.java:296)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
  at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
  at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:945)
  at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:909)
  at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:269)
  at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:392)
  at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:274)
  at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)



페이지 맨 위

장시간 실행되는 SQL 쿼리 
장시간 실행되는 SQL 쿼리는 호출하는 응용 프로그램에 결과를 반환할 때까지 Execute 스레드를 점유합니다. 따라서 응용 프로그램 로드에 의해 요청된 호출을 동시에 여러 개 처리할 수 있도록 WebLogic Server 인스턴스를 구성해야 합니다. 이 경우 제한 요인은 JDBC 커넥션 풀의 Execute 스레드 및 커넥션 수입니다. 또한 가장 중요한 일반 규칙은 리소스 사용량을 최적화하기 위해서는 풀의 커넥션 수를 Execute 스레드 수와 동일하게 설정해야 한다는 것입니다. JTS를 사용하는 경우 실제로 활성화되지 않은 트랜잭션에 대해 커넥션이 확보될 수 있으므로 풀에 커넥션 수를 좀 더 많이 설정해야 합니다.

장시간 실행되는 SQL 호출에서 Hang(정지)되는 스레드의 경우 스레드 덤프에 Hang(정지) 상태의 데이터베이스와 매우 유사한 스택이 표시됩니다. 자세한 내용은 다음 단원에서 비교해 보십시오.

Hang(정지) 상태의 데이터베이스 
데이터베이스를 사용하는 응용 프로그램의 성능은 해당 데이터베이스의 성능에 의해 가장 크게 좌우됩니다. 따라서 Hang(정지) 상태의 데이터베이스는 WebLogic Server 인스턴스의 Execute 스레드 중 대부분 또는 일부를 차단시킬 수 있으며 결과적으로 서버 Hang(정지) 상태를 발생시킵니다. 이러한 문제를 진단하려면 Hang(정지) 상태의 WebLogic Server 인스턴스에서 5개 내지 10개의 스레드 덤프를 통해 Execute 스레드가 현재 SQL 호출에 참가하고 있는지, 그리고 데이터베이스의 결과를 기다리고 있는지 확인해야 합니다. 다음은 현재 SQL 쿼리를 보낸 스레드에 대한 스택 트레이스의 일반적인 예입니다.


"ExecuteThread: '4' for queue: 'weblogic.kernel.Default'" daemon prio=5 tid=0x8e93c8 nid=0x19 runnable [e137f000..e13819bc]
  at java.net.SocketInputStream.socketRead0(Native Method)
  at java.net.SocketInputStream.read(SocketInputStream.java:129)
  at oracle.net.ns.Packet.receive(Unknown Source)
  at oracle.net.ns.DataPacket.receive(Unknown Source)
  at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
  at oracle.net.ns.NetInputStream.read(Unknown Source)
  at oracle.net.ns.NetInputStream.read(Unknown Source)
  at oracle.net.ns.NetInputStream.read(Unknown Source)
  at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:931)
  at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)
  at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:375)
  at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1983)
  at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java:1250)
  - locked <e8c68f00> (a oracle.jdbc.ttc7.TTC7Protocol)
  at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2529)
  at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2857)
  at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:608)
  - locked <e5cc44d0> (a oracle.jdbc.driver.OraclePreparedStatement)
  - locked <e8c544c8> (a oracle.jdbc.driver.OracleConnection)
  at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:536)
  - locked <e5cc44d0> (a oracle.jdbc.driver.OraclePreparedStatement)
  - locked <e8c544c8> (a oracle.jdbc.driver.OracleConnection)
  at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:80)
  at myPackage.query.getAnalysis(MyClass.java:94)
  at jsp_servlet._jsp._jspService(__jspService.java:242)
  at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
  at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971)
  at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402)
  at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
  at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:607)
  at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:400)
  at weblogic.servlet.jsp.PageContextImpl.include(PageContextImpl.java:154)
  at jsp_servlet._jsp.__mf1924jq._jspService(__mf1924jq.java:563)
  at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
  at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971)
  at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402)
  at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
  at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6350)
  at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
  at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
  at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3635)
  at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585)
  at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
  at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)


스레드는 실행 상태가 됩니다. 여러 스레드 덤프의 스레드를 비교하여 SQL 호출로부터 적절한 시간 내에 응답을 받는지 아니면 동일한 호출에서 장시간 Hang(정지)되어 있는지 확인해야 합니다. 스레드 덤프에서 SQL 호출 응답 시간이 너무 긴 것으로 확인되면 해당 데이터베이스 로그를 통해 이러한 성능 저하나 Hang(정지) 상태가 데이터베이스 문제 때문에 발생한 것인지 확인해야 합니다.

페이지 맨 위

느린 네트워크 
WebLogic Server와 데이터베이스 간의 통신이 이루어지고 적절한 시간 내에 요청이 처리되기 위해서는 네트워크가 정상적으로 작동하고 안정적이어야 합니다. 따라서 네트워크가 느리면 SQL 쿼리의 결과를 기다리는 Execute 스레드가 Hang(정지)되거나 차단될 수 있습니다. 관련 스택 트레이스는 Hang(정지) 상태의 데이터베이스 단원의 예제와 비슷합니다. WebLogic Server 스레드 덤프만 분석해서는 SQL 쿼리가 Hang(정지)되거나 느려지는 근본 원인을 알 수 없습니다. 스레드 덤프는 SQL 호출의 성능에 문제가 있음을 파악할 수 있는 초기 징후라 할 수 있습니다. 다음 단계로 SQL 호출 성능 저하의 원인이 데이터베이스 문제인지 아니면 네트워크 문제인지를 확인해야 합니다.

데드락
데이터베이스 수준의 데드락과 응용 프로그램 수준의 데드락은 스레드를 Hang(정지) 상태로 만들 수 있습니다. 응용 프로그램 수준 데드락이 있는지 알아보려면 스레드 덤프를 확인해야 합니다. 이 작업을 수행하는 방법은 ServerHang - 응용 프로그램 데드락(Deadlock) 패턴을 참조하십시오. 데이터베이스 데드락은 데이터베이스 로그 또는 WebLogic Server 로그 파일의 SQL Exception을 통해 확인할 수 있습니다. 다음은 관련 SQL Exception의 예입니다.


java.sql.SQLException: ORA-00060: deadlock detected while waiting for resource
  at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:170)
  at oracle.jdbc.oci8.OCIDBAccess.check_error(OCIDBAccess.java:1614)
  at oracle.jdbc.oci8.OCIDBAccess.executeFetch(OCIDBAccess.java:1225)
  at oracle.jdbc.oci8.OCIDBAccess.parseExecuteFetch(OCIDBAccess.java:1338)
  at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1722)
  at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1647)
  at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2167)
  at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:404)


일반적으로 데이터베이스에서 데드락이 감지되고 원인이 된 하나 이상의 트랜잭션을 롤백하여 데드락을 해결하기까지는 다소 시간이 걸리기 때문에 롤백이 끝날 때까지 하나 이상의 Execute 스레드가 차단될 수 있습니다.

RefreshMinutes 또는 TestFrequencySeconds
데이터베이스 성능 저하, SQL 호출 속도 저하 또는 최다 커넥션이 주기적으로 반복되는 경우 JDBC 커넥션 풀에 설정된RefreshMinutes 또는 TestFrequencySeconds 구성 속성이 원인일 수 있습니다. 자세한 내용은 JDBC 문제 조사 패턴을 참조하십시오. WebLogic Server 인스턴스와 데이터베이스 사이에 방화벽이 없는 경우 외에는 이 기능을 사용하지 말아야 합니다.

풀 축소 
새로운 커넥션 요청은 데이터베이스, 운영 체제 커널 및 WebLogic Server에 상당한 리소스 오버헤드를 발생시키므로 데이터베이스에 대한 커넥션을 한 번 열면 가능한 한 오랫동안 유지해야 합니다. 따라서 이러한 오버헤드를 최소한으로 유지하려면 운영 시스템에서 풀 축소를 사용하지 말아야 합니다. 풀 축소를 사용하면 유휴 풀 커넥션이 닫히게 되고 풀에서 커넥션 요청을 처리할 수 없는 경우에 다시 열립니다.

이와 같은 작업에는 다소 시간이 걸릴 수 있으므로 관련 응용 프로그램 요청에 시간이 예상 외로 많이 걸려 사용자가 시스템이 Hang(정지)되었다고 판단할 수 있습니다. JDBC 커넥션 풀 구성을 최적화하는 방법에 대한 자세한 내용은 JDBC 문제 조사 패턴을 참조하십시오.

페이지 맨 위

Hang(정지) 상태의 WebLogic Server 인스턴스 분석
Hang(정지) 상태의 WebLogic Server 인스턴스를 분석하는 방법에 대한 자세한 내용은 일반적인 서버 Hang(정지) 패턴을 참조하십시오. 

시스템이 Hang(정지)되는 경우 대개 문제를 파악하려면 먼저 Hang(정지) 상태의 시스템에서 스레드 덤프를 확인하는 것이 좋습니다. 예를 들어 여러 스레드가 어떤 작업을 수행하고 있는지, 왜 Hang(정지)되었는지 등을 확인합니다. 일반적으로 스레드 덤프는 운영 시스템에서 생성할 수 있지만 오래된 JVM 버전(1.3.1_09 이전 버전)의 경우 스레드 덤프를 생성하는 동안 크래시가 발생할 수 있으므로 주의해야 합니다. 또한 WebLogic Server 인스턴스에 막대한 수의 스레드가 있는 경우 스레드 덤프를 완료하는 데 상당한 시간이 소요되고 그 동안 나머지 스레드가 잠기게 됩니다.

지연 시간이 몇 초 이내인 스레드 덤프를 두 개 이상(5-10개) 생성하십시오. 그러면 다른 스레드의 진행 상태를 확인할 수 있습니다. 또한 시스템이 실제로 Hang(정지)되어 작업이 전혀 진행되지 않거나 처리가 느려 시스템이 Hang(정지)된 것처럼 보이는 경우 이러한 내용이 표시됩니다.

스레드 덤프를 생성하는 방법에 대한 자세한 내용은 "일반적인 서버 Hang(정지)" 지원 패턴 또는 http://e-docs.bea.com/wls/docs81/cluster/trouble.html의 설명서를 참조하십시오.

또한 전체 WebLogic Server 인스턴스가 Hang(정지)된 것인지 아니면 응용 프로그램이 Hang(정지)된 것인지를 확인하십시오.스레드 덤프를 분석하면 앞의 문제 발생 원인 단원에서 설명한 여러 가지 원인 중에서 인스턴스 Hang(정지)의 실질적인 원인을 알아낼 수 있습니다. 예를 들어 모든 스레드가 getConnection()과 같은 DriverManager 메쏘드에 있는 경우 근본 원인을 파악한 다음에 DriverManager.getConnection() 대신 DataSource 또는 Driver.connect()를 사용하도록 응용 프로그램을 변경해야 합니다.

Samurai라는 유용한 도구를 사용하여 스레드 덤프를 분석하고 여러 스레드 덤프 간에 스레드 진행 상태를 모니터할 수 있습니다. Samurai는 dev2dev 웹 사이트 http://dev2dev.bea.com/resourcelibrary/utilitiestools/adminmgmt.jsp에서 다운로드할 수 있습니다.

또한 dev2dev 웹 사이트 http://dev2dev.bea.com/products/wlplatform81/articles/thread_dumps.jsp에 있는 스레드 덤프 분석에 관한 백서를 통해 스레드 덤프와 서버 Hang(정지)에 대해 자세히 알아볼 수 있습니다. 

페이지 맨 위

JDBC 코드 및 JDBC 커넥션 풀 구성 최적화를 위한 팁과 유용한 정보
JDBC 코드 개발 또는 JDBC 커넥션 풀 구성 시에 일반적인 문제 발생을 방지하고 리소스 사용량을 최적화하여 서버 인스턴스 Hang(정지)이 발생하지 않도록 하는 데 도움이 되는 몇 가지 모범 사례를 적용할 수 있습니다.

JDBC 프로그래밍 
WebLogic Server에서 리소스 사용량을 최적화하고 데이터베이스 리소스를 절약하려면 응용 프로그램의 JDBC 호출에 JDBC 커넥션 풀을 사용해야 합니다. 응용 프로그램 코드에서 만들어지고 제거되는 커넥션은 불필요한 오버헤드를 발생시킵니다. JDBC 프로그래밍에 대한 자세한 내용은 http://e-docs.bea.com/wls/docs81/jdbc/rmidriver.html#1028977을 참조하십시오. 또한 JDBC 성능 조정에 대한 자세한 내용은 http://e-docs.bea.com/wls/docs81/jdbc/performance.html#1027791을 참조하십시오.

JDBC 코드 및 JDBC 리소스 사용량을 최적화하는 데 유용한 포괄적인 JDBC 관련 정보는 dev2dev Java Database Connectivity 페이지(http://dev2dev.bea.com/technologies/jdbc/index.jsp)를 참조하십시오.

JDBC 커넥션 풀 구성
JDBC 문제 조사 패턴에는 운영 환경의 커넥션 풀 구성에 대한 권장 사항이 나와 있습니다. Hang(정지)이나 성능 저하를 방지하려면 이러한 구성 팁을 고려해야 합니다. 


페이지 맨 위

알려진 문제
사용하고 있는 WLS 버전의 릴리스 정보를 주기적으로 검토하여 서비스 팩에서 알려진 문제나 해결된 문제를 확인하고 JDBC 서버 Hang(정지) 관련 문제를 검색할 수 있습니다. 간편하게 다음을 참조하십시오. 
드라이버가 현재 실행 중인 명령문이 반환될 때까지 기다려야 하기 때문에 특정 JDBC 커넥션에 대해 트랜잭션 롤백 호출이 바로 처리되지 않는 CR134921 오류는 WLS 8.1 SP3에서 해결되었습니다. 

검색하면 릴리스 정보뿐 아니라 추가 도움말에서 언급된 기타 지원 솔루션 및 CR 관련 정보도 알 수 있습니다. 계약 고객은http://support.bea.com/에 로그인한 다음 Browse 포틀릿에서 Solutions 및 Bug Central을 검색하여 제품 버전별로 사용 가능한 최신 CR을 찾을 수 있습니다. 


Posted by GUCCI
, |

최근에 달린 댓글

글 보관함