Czy mogę ryzykować wyciek połączenia JDBC podczas przesyłania strumieniowego wyników JOOQ poza blokiem try-with-resources?

Question

Mam zapytanie JOOQ, w którym chcę uniknąć materializowania wszystkich rekordów w tym samym czasie. (Jestem jednak dobrze ze wspólnie materializacji wszystkie obiekty fasoli utworzone z nich).

mam następujący prosty sposób załadować dane:

public List<CustomerInfo> getCustomers() { 
    return dslContext 
       .selectFrom(CUSTOMER) 
       // <-- note the missing .fetch() 
       .stream() 
       .map(CustomerInfo::new) 
       .collect(Collectors.toList()); 
} 

Może to prowadzić do nieszczelności połączenia JDBC w żadnych okolicznościach ? (Np wyjątek w CustomerInfo::new)

Answer 1

Próbowałem szczęścia znalezienie sposobu rejestrowania niezawodnego strumienia „ukończenie” haka, że ​​pożary na całkowitym zużyciu strumienia lub na każdy wyjątek, ale to nie jest możliwe, niestety: Register a Stream "completion" hook

Rzeczywiście, kod, który pokazałeś, jest nieprawidłowy. Prawidłowym sposobem działania z "leniwymi" strumieniami (lub Cursor) jest użycie instrukcji try-with-resources. Następujące dwa są równoważne

// Using a Stream 
try (Stream<CustomerRecord> stream = dslContext.selectFrom(CUSTOMER).stream()) { 
    return stream.map(CustomerInfo::new).collect(Collectors.toList()); 
} 

// Using a Cursor 
try (Cursor<CustomerRecord> cursor = dslContext.selectFrom(CUSTOMER).fetchLazy()) { 
    return cursor.stream().map(CustomerInfo::new).collect(Collectors.toList()); 
} 

Wskazówki również ResultQuery.stream() javadoc:

ta jest zasadniczo taka sama jak fetchLazy(), ale zamiast wrócić kursor, Java 8 strumień jest zawracany. Klienci powinni upewnić się, że strumień jest właściwie zamknięty, np. w instrukcji try-with-resources