Connections 대 데이터 소스

Question

Java에 대한 연결 대 데이터 소스에 대해 읽었으며 몇 가지 질문이 있습니다. 데이터 소스는 실제로 관리자 일 뿐이며 연결 (또는 다중 연결)의 추상화입니까?

Answer 1

:

이 DataSource 객체가 나타내는 물리 데이터 소스에의 접속에 대한 팩토리. DriverManager 기능의 대안으로 DataSource 객체가 연결을 얻는 가장 좋은 방법입니다.

사실하는 DataSourceConnection는 S의 벤더이며 상이한 방식으로 동작하는 다양한 실시있다. 예를 들면 :

1. 기본 구현 - 표준 Connection 객체를

2. 연결 풀링 구현을 생성 - 자동적으로 접속 풀에 참가하는 Connection 오브젝트를 생성한다. 이 구현은 중간 계층 연결 풀링 관리자와 함께 작동합니다.

3. 분산 트랜잭션 구현 - 분산 트랜잭션에 사용할 수있는 Connection 개체를 생성하며 거의 항상 연결 풀링에 이 참여합니다. 이 구현은 중간 계층 트랜잭션 관리자에서 작동하며 거의 항상 연결 관리자 풀링 관리자로 작동합니다. 이는 처음부터와 통신 할 수있는 SQL 연결을 리턴해서는 안됩니다 추상적 인 상호 작용을 의미하는 것처럼

Answer 2

데이터 원본은 데이터 원본이며, 연결은 드라이버입니다.

Answer 3

연결은 연결입니다. DataSource는 연결 관리자입니다 (연결 풀).

docs에서

Answer 4

데이터 소스는 기존의 형태로 병 개념이다. 또한 과잉이며 XA는 환상적인 개념입니다. 일부는 세계에서 안정적인 구현이 부족하여 값 비싼 대가를 치르고 있습니다. (모든 기업의 상용 구현자는 간단히 실패하고 비즈니스를 노출합니다 ... 누군가 금융으로 인해 상처를 입었지만 언급하지 않을 것입니다. 이름). 일반적으로 썬이나 오라클의 권장 사항과 상관없이 오버 엔지니어링과 코드에 기술적 인 문제가 발생합니다 (컨텍스트, 데이터 접근을위한 추가 단계, 일부 외부 구성 ...). 결국에는 벤더 구현). 일부는 엔터프라이즈 DBMS 공급 업체가 제공하는 DataSource 구현보다 일반 연결 및 DriverManager를 기반으로 훨씬 더 나은 풀링, 연결 복구 e.t.c를 처리하는 코로 포 레이션 솔루션을 개발했습니다.

기록을 위해 나는 둘 다에서 일했고 나는 다른 곳에서 마주 치게되는 사실에 기반을 둔다. 그리고 의심 스러울 경우 하이버 네이트 구성에서 일반 JDBC URL을 비즈니스의 모든 곳에서 볼 수있는 이유를 묻습니다. 많은 사람들은 J2EE에 대한 heavyweigtt 아이디어를 버리고 가볍게 진행합니다 ... 또한 DriverManager 기반의 일반 연결을 사용합니다.

온라인 상태에서 경력을 쌓고 XA 데이터 소스를 사용하고 XA 구현이 잘못되어 실패한 트랜잭션을 복구하려고합니다.