You can workaround it by setting:

openjpa.jdbc.DBDictionary = mysql(supportsCorrelatedSubselect=false)

This will force openjpa to revert to in-memory bulk operation. Be warned 
that it'll be grossly inefficient for anything beyond a few rows, as 
openjpa will select the rows matching your where clause and then issue a 
separate delete statement for each row. The only alternative is to 
fallback to plain JDBC prepared statements.

That's actually a rather nasty issue, all bulk operations involving a 
where clause against mysql fail because of that. Since I'm writing a 
very performance-aware app myself, I've dug deep into fixing it but I 
can't find a sensible way to do it. DBDictionary.toBulkOperation() 
relies on the select statement passed to it to build the final bulk 
update/delete statement, and that select always has table aliases 
embedded to it, even if where clause spans a single table as in Ognjen's 
example.

If Patrick or any openjpa veteran can offer a strategy to fix it, I'll 
gladly put in the time to implement it.

Ognjen Blagojevic wrote:
> I try to do an update by query like this
>
>  em = emf.createEntityManager();
>  em.getTransaction().begin();
>  Query q = em.createQuery(
>    "UPDATE SifTipInstitucije o SET o.nazivEngleski='someText' WHERE 
> o.idTipInstitucije = 1");
>  int updated = q.executeUpdate();
>  em.getTransaction().commit();
>  em.close();
>
> But it seems that OpenJPA (1.0.0) translates this into
>
> UPDATE sif_tip_institucije
>    SET naziv_engleski = ?
>  WHERE id_tip_institucije IN
>        (SELECT DISTINCT t0.id_tip_institucije
>           FROM sif_tip_institucije t0
>          WHERE (t0.id_tip_institucije = ?))
>
> [params=(String) someText, (long) 1]
>
> Which is not legal MySQL query... It throws the exception:
>
> You can't specify target table 'sif_tip_institucije' for update in 
> FROM clause.
>
> Is this a bug? Should I log a JIRA?
>
> Regards,
> Ognjen