@Lob 사용시 DB와 엔티티 필드 타입이 다른 경우 발생하는 문제와 해결방법

😫 배경

진행 중인 프로젝트의 과거 코드 중 HTML 문서를 그대로 DB에 저장하는 내용이 있었다. HTML 문서 내용은 동적이고, 길이가 길었기 때문에 긴 문자열 저장을 위해 LOB을 사용했고, 별다른 문제없이 서비스를 이용해 왔었다. 그러다 어느 순간 서비스를 이용할 수 없는 문제가 발생했다. 이와 관련해서 파악한 원인과 해결 방법에 대해서 공유하고자 한다.

🔎 원인

문제 내용을 분석해 보니, 'DB에 선언된 LOB 타입'과 '엔티티에 사용된 @LOB 타입'이 다르게 사용되었기 때문에 발생한 문제였다.

 

서비스 DB에서는 BLOB 타입을 적용시켰는데, 막상 엔티티 필드에서는 String 타입으로 선언했기 때문에 CLOB 관련 로직이 적용되면서 데이터베이스에서 가져온 데이터를 처리할 수 없게 되어 문제가 발생한 것이다.

 

@Lob 사용 시 스프링은 필드 타입에 따라 자동으로 관련 jdbc 객체로 연결해 주는데, 컴파일 단계에서는 이를 확인할 수 없으므로 해당 문제를 파악할 수 없었다.

발생한 문제

1. Invalid UTF8  

CLOB은 기본적으로 UTF8 인코딩을 가정한다. 그러므로 데이터를 가져올 때 길이를 계산하는 과정에서 UTF-8을 적용해서 길이를 계산한다.

MariaDbClob.java

  public long length() {
    // The length of a character string is the number of UTF-16 units (not the number of characters)
    long len = 0;
    int pos = offset;

    // set ASCII (<= 127 chars)
    while (len < length && data[pos] > 0) {
      len++;
      pos++;
    }

    // multi-bytes UTF-8
    while (pos < offset + length) {
      byte firstByte = data[pos++];
      if (firstByte < 0) {
        if (firstByte >> 5 != -2 || (firstByte & 30) == 0) {
          if (firstByte >> 4 == -2) {
            if (pos + 1 < offset + length) {
              pos += 2;
              len++;
            } else {
              throw new UncheckedIOException("invalid UTF8", new CharacterCodingException());
            }
          } else if (firstByte >> 3 != -2) {
            throw new UncheckedIOException("invalid UTF8", new CharacterCodingException());
          } else if (pos + 2 < offset + length) {
            pos += 3;
            len += 2;
          } else {
            // bad truncated UTF8
            pos += offset + length;
            len += 1;
          }
        } else {
          pos++;
          len++;
        }
      } else {
        len++;
      }
    }
    return len;
  }

 

해당 부분에서 BLOB 타입 데이터를 길이를 계산하는 과정 중 문제가 발생하여 "invalid UTF8" 메시지와 함께 UncheckedIOException 예외가 발생하게 된다.

 

MariaDbBlob.java 파일의 length() 메서드는 데이터 길이 그대로를 반환한다.

 

  public long length() {
    return length;
  }

2. Data type BLOB cannot be decoded as Clob

해당 문제는 1번 문제를 재연하려고 했을 때 조회 과정 테스트에서 발생한 예외이다.

(스프링 부트 버전이 업그레이드되면서 length 이전에 필터링되는 것으로 추측된다.)

ClobCodec.java

  @SuppressWarnings("fallthrough")
  private Clob getClob(ReadableByteBuf buf, int length, Column column) throws SQLDataException {
    switch (column.getType()) {
      case BLOB:
      case TINYBLOB:
      case MEDIUMBLOB:
      case LONGBLOB:
        if (column.isBinary()) {
          buf.skip(length);
          throw new SQLDataException(
              String.format("Data type %s cannot be decoded as Clob", column.getType()));
        }
        // expected fallthrough
        // BLOB is considered as String if it has a collation (this is TEXT column)

      case STRING:
      case VARCHAR:
      case VARSTRING:
        Clob clob = new MariaDbClob(buf.buf(), buf.pos(), length);
        buf.skip(length);
        return clob;

      default:
        buf.skip(length);
        throw new SQLDataException(
            String.format("Data type %s cannot be decoded as Clob", column.getType()));
    }
  }

 

column 타입을 확인해서, Blob 타입인 경우 SQLDataException 예외가 발생한다.

조회 과정에서 발생하는 문제이므로, 데이터를 저장하기만 한다면 문제가 발생하지 않는다. 

해결방법

HTML 문자를 그대로 저장하다 보니 데이터가 BLOB보다 CLOB 타입에 어울린다고 생각해서 DB 데이터 유형을 CLOB 타입으로 수정하려고 했다. 하지만 변경 과정에서 UTF8 문제가 발생하며 수정에 실패했다.

(이미 DB 내에 많은 데이터가 쌓여 있었고, 저장된 데이터 중 UTF8로 인식할 수 없는 데이터가 존재하였음)

 

@Lob 어노테이션을 제거하면 Lob 처리 과정을 생략하기 때문에 해당 방법을 선택해서 문제를 해결했다.

결론

@Lob을 사용하기 전에 저장될 데이터 유형이 BLOB, CLOB 중 어떤 타입이 맞을지 잘 고민해서 정해야 하고, 데이터베이스 타입과 필드 타입은 반드시 맞춰야 한다.