To samo zapytanie w tej samej bazie danych daje różne wyniki w usłudze OAS 10.1.3

Question

Widzę coś dziwnego, gdy uruchamiam zapytanie w aplikacji wdrożonej w produkcie Oracle Application Server 10.1.3, z Oracle10g.

Kiedy uruchamiam oświadczenie w bazie danych bezpośrednio (np samodzielna aplikacja, która wywołuje DAO realizowany z hibernacji) Widzę następujące:

select 
    documentco0_.CONTENT_ID as CONTENT1_63_0_, 
    documentco0_.TSTAMP as TSTAMP63_0_, 
    documentco0_.CONTENT as CONTENT63_0_ 
from 
    MySchema.MyTable documentco0_ 
where 
    documentco0_.CONTENT_ID=? 

[main] TRACE org.hibernate.type.LongType - binding '1768334' to parameter: 1 
[main] TRACE org.hibernate.type.TimestampType - returning '2013-08-05 17:31:32' as  column: TSTAMP63_0_ 
[main] TRACE org.hibernate.type.BinaryType - returning '7f587f608090cac6c9c68081818180b380b380807f5b80c3807f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f40808b8880918091818191807f44809f8080818581818181818180808080808080808182838485868788898a8b7f44803590808281838382848385858484808081fd8182838084918592a1b1c18693d1e187a2f194b201112188a3c2314195d25170a4b3e2f202898a969798999aa5a6a7a8a9aab4b5b6b7b8b9bac3c4c5c6c7c8c9cad3d4d5d6d7d8d9dae3e4e5e6e7e8e9eaf3f4f5f6f7f8f9fa030405060708090a12131415161718191a22232425262728292a32333435363738393a42434445464748494a52535455565758595a6162636465666768696a7172737475767778797a7f5a808881818080bf80fef947bf520c730eff25ada7bd007c7f807a460efd87677f805625220aab7f59' as column: CONTENT63_0_ 

Ta sama operacja DAO w przypadku uruchomienia w serwerze aplikacji jednak powraca następujące:

select 
    documentco0_.CONTENT_ID as CONTENT1_63_0_, 
    documentco0_.TSTAMP as TSTAMP63_0_, 
    documentco0_.CONTENT as CONTENT63_0_ 
from 
    MySchema.MyTable documentco0_ 
where 
    documentco0_.CONTENT_ID=? 

2013-08-06 12:49:46,484 TRACE [AJPRequestHandler-RMICallHandler-12] myuser:4 (NullableType.java:133 nullSafeSet()) - binding '1768334' to parameter: 1 
2013-08-06 12:49:46,500 TRACE [AJPRequestHandler-RMICallHandler-12] myuser:4 (NullableType.java:172 nullSafeGet()) - returning '2013-08-05 17:31:32' as column: TSTAMP63_0_ 
2013-08-06 12:49:46,500 TRACE [AJPRequestHandler-RMICallHandler-12] myuser:4 (NullableType.java:172 nullSafeGet()) - returning '80d48081818c808080818080808180808099ff0c809a5c9d809a5c9c80828082808080817f587f608090cac6c9c68081808080804818f7ef8081808080808080808080808080808080808080809a5c9c83408c508081' as column: CONTENT63_0_ 

można zobaczyć, że identyfikator i datownik są takie same w obu przypadkach, ale kropelka treść jest inna: 360 bajtów w pierwszym przypadku i 86 bajtów w drugim przypadku.

Aplikacja autonomiczna korzysta z BasicDataSource, a aplikacja na serwerze używa źródła danych JNDI. Zweryfikowałem, że BasicDataSource zawiera ten sam adres URL JDBC, który jest używany w źródle danych JNDI. Oba źródła danych używają tych samych poświadczeń.

Operacja bazy danych na serwerze aplikacji ma inne wyjście śledzenia, z wykorzystaniem NullableType::nullSafeGet() do wyświetlania informacji zamiast śledzenia org.hibernate.type. Nie jestem pewien, czy to jest istotne.

Czy jest coś oczywistego, co tu widzę? Nie widzę powodu, dla którego uzyskuję różne wyniki podczas uruchamiania tego samego zapytania w tej samej bazie danych. edit: on OAS Skonfigurowałem JDBC ConnectionPool, który używa klasy fabryki połączeń oracle.jdbc.pool.OracleDataSource, a źródłem danych JDBC jest zarządzane źródło danych wskazujące na tę pulę połączeń.

Myślę, że może być problem z różnymi sterownikami Oracle JDBC? Wersja BasicDataSource dla samodzielnej aplikacji używa sterownika JDBC oracle.jdbc.driver.OracleDriver i dialektu org.hibernate.dialect.Oracle10gDialect. Nie widzę żadnego miejsca w administracji OAS, które pokazuje równoważne wartości.

Answer 1

Proszę spojrzeć na this article

Wygląda na to, z jakiegoś powodu, OAS zwraca tylko 86 bajtów o wartości BLOB, chyba można określić procedurę obsługi lob konfiguracji.

Można również mieć więcej informacji na this thread of CodeRanch opisujące ten sam problem

nadzieję, że to pomaga!