Carsten Hammer Actually, I do not see the behavior you suggest happens. I went ahead and added some specific tests for asserting how AttributeConverters inter-operate with caching. What I found is that the second level cache actually holds the converted value. I'll be pushing my tests momentarily, but as an example what I have is:

@Entity
@Cacheable
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Address {
	@Id
	Integer id;
	String streetLine1;
	String streetLine2;
	@Convert(converter = PostalAreaConverter.class)
	PostalArea postalArea;

	...
}


public enum PostalArea {
	_78729( "78729", "North Austin", "Austin", State.TX );

	private final String zipCode;
	private final String name;
	private final String cityName;
	private final State state;

	...
}

public class PostalAreaConverter
		implements AttributeConverter<PostalArea, String> {
	static int toDatabaseCallCount = 0;
	static int toDomainCallCount = 0;

	@Override
	public String convertToDatabaseColumn(PostalArea attribute) {
		toDatabaseCallCount++;
		if ( attribute == null ) {
			return null;
		}
		else {
			return attribute.getZipCode();
		}
	}

	@Override
	public PostalArea convertToEntityAttribute(String dbData) {
		toDomainCallCount++;
		if ( dbData == null ) {
			return null;
		}
		return PostalArea.fromZipCode( dbData );
	}

	static void clearCounts() {
		toDatabaseCallCount = 0;
		toDomainCallCount = 0;
	}
}

And the results are exactly what you suggest. I populated the cache from both save/persist and load. In each case the PostalArea (the converter's "domain state") is saved into the cache rather than the PostalArea#zipCode String (the converter's "database state"). In the case of save/persist exactly one call is made to the converter's #convertToDatabaseColumn method (no calls to #convertToEntityAttribute), and in the case of load exactly one call is made to the converter's #convertToEntityAttribute method (no calls to #convertToDatabaseColumn).

As I keep saying you just seem to have not set this up properly.

Now, I can actually verify this reported bug specifically (not Carsten Hammer's additional assertions). If I add @Lob to the Address#postalArea attribute, things break down:

	@Lob	
	@Convert(converter = PostalAreaConverter.class)
	PostalArea postalArea;

leads to similar problem as reported in the original report:

java.lang.ClassCastException: org.hibernate.test.converter.caching.PostalArea cannot be cast to org.hibernate.engine.jdbc.CharacterStream

	at org.hibernate.type.descriptor.sql.ClobTypeDescriptor$4$1.doBind(ClobTypeDescriptor.java:124)
	at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:74)

At the moment this process is allowed to be influenced by the Dialect you are using (as part of the sql-type remapping support) which is why it does not always show up. Anyway, I have a test reproducing this and am working on a solution.