Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues

On 9 January 2012 14:29, Stefan Keller <sfkeller(at)gmail(dot)com> wrote:
> 2012/1/9 Oliver Jowett <oliver(at)opencloud(dot)com>:
>> As a LO is independent storage that might have multiple references to> it (the OID might be stored in many places), without explicit deletion> you need a GC mechanism to collect unreferenced LOs eventually -> that's what vacuumlo etc are doing.
> I can follow that. But that's not what the JDBC user expects nor is it
> explained (nor mentioned) in the JDBC docs.
>
> From a conceptual view I have just an entity MyWebcam with an
> attribute called image. Attribute image is of attribute cardinality
> 1:1 (and private):
>
> // Java using Hibernate/JPA:
>  @Entity
>  @Lob
>  @Basic(fetch=FetchType.LAZY)
>  public class MyWebcam {
>    private byte[] image;
>    private String name;
>    public byte[] getImage() { return image; }
>    public void setImage(byte[] _image) { image=_image; }
>    // ... other stuff
>  }
>
> That's the classic use case.
> Isn't it obvious that if setImage() sets another byte[] that the image
> space get's cleared by the layers below?
> And since Hibernate chose to use one variant of JDBC, it's also JDBC
> which has to take care about orphans.

Well, either the Hibernate mapping is misconfigured, or your database
is misconfigured i.e. you are not collecting garbage LOs. If you have
a suitable GC mechanism configured, then what happens?

Otherwise, what should JDBC do differently here? Be specific. It would
be helpful if you could provide a native JDBC example, rather than a
Hibernate example, since it's not clear what JDBC calls are being made
by Hibernate.

Oliver