I have a requirement to archive certain classes of entity beans that are deleted by users in our system. We already use XML extensively for communications between client program to back end over HTTP, so I have a factory for making every entity into an XML document.
Anyway the idea I hit upon is to introduce a new EJB into the system called XMLArchive which has a PK and a field to contain the XML string of the object to be deleted (plus some others like date deleted and so on which need not concern us here). The Archive PK is generated from the pk.toString() of the deleted EJB's primaryKey class and the hashcode of the remote EJB stub. The ejbCreate of the Archive Bean class takes type of EJBObject (ie a remote stub) so this is all done when the bean is created.
Would it be possible or desirable to put the call to the XMLArchive bean into the ejbRemove() of the desired EJB types thereby making sure that no matter how deletion is achieved (i.e. even if the facade is somehow bypassed) the object is archived?
Is this an anti-pattern or a pattern, a good or bad idea? Your thoughts are appreciated, thank you.
First, perhaps database vendors provide such "backup" facilities one can make use off.
Second, how 'fast' is your archiving going to be? I mean ejbRemove is supposed to delete data from the database. And here we are trying to insert data in another table as well.
Third, what happens if the insert fails? Would you fail the remove? Perhaps what you want to do is application specific.
Fourth, are you really looking for a "backup" or "paper trail".
Fifth, perhaps you may want to consider using database triggers? I am no expert in this area but I would like to believe you can write a trigger that will store data being deleted into another table massaged into any format you want. And of course, this insert will be transaction and will fail along with the remove of the original data. But at least you can simply drop to trigger when you don't wanna archive anymore.
You could simply set a deleted flag on the records, instead of actually deleting the row. That's what I have done in the past.