Hibernate version:
2.1.7c

When I do:

MyClass obj =(MyClass)so.session.load(MyClass.class,new Long(id));
session.delete(obj);

it still results in a select, and then a delete statement. If MyClass is proxied shouldn't it not have a select statement since the delete (should) only require the identifier column.

Depends. You can set a class mapping to perform a "select-before=update," which in a highly concurrent environment is advantageous. It is very possible, for example, that another user in another application could have deleted the object in question. If the delete occurs outside the current Hibernate session, there's no way Hibernate can know that the delete occurs. So, Hibernate must do a check to verify that the object exists before it issues the delete.

Take a look at the select-before-update documentation in:
http://www.hibernate.org/hib_docs/refer ... tion-class

Also, your object could be in a detached state. If that's the case, I believe deleting the object will cause its persistent state to be updated from the database (translation: a select to the DB). I'm not 100% on this, so experimentation may be in order. Check out section 4.2.6 in Hibernate in Action for more information. If this is the case, then examine why your object is detached in the first place. Did you intend for the object to be detached? Could you use a ThreadLocal/Open Session In View pattern to keep the sesion open, etc.

Hmm, well basically the solution I'm going to do is to have to write a custom delete(query) that uses my lazy object that only gets the PK, and thus does not require a load. It just seems to me that a delete(object) where object is lazy, should not require a select.

The concurrency problem you suggested is solved by changing the transaction level isolation. Adding extra selects doesn't help.