hi,

At 14:51 18.07.2003 -0400, you wrote:

I think I have a better idea of what you are doing.  I see you are using entity beans.  My comments would be:
 
1)  As I mentioned in my earlier msg, you don't need to synchronize your methods; the database resource manager will do this for you.  There are a number of ways of doing this, since you are using EJBs, the main point is to implement an EJB Business Method that will replace the functionality of lockKeywords.  (Obviously you can wrap the call to this EJB in a rewritten version of lockKeywords if you must preserve the method signature for you clients).
 
2)  You code would probably perform better and be simpler if you created a new database table called something like Document_Lock, that would be independent of your history table.  This would carry the lock status in one record for each mandant, and you would write history records out as each entry in this table would be created or updated.  (This is a suggestion only.  One downside is that either have to create the entry representing the mandant at the time the document was created, or create it the first time a user attempted to set the lock on the document.  I assume here that it has already been created.)

We was speeking with other developers to create a special table. I thing the best way for lock will be create a UNIQUE INDEX on special columnt. that thre could be only a one entry in the db. If you try to create a new entry thrue EB, you get an CreateException if the exists allready on entry. otherwise you have your lock.

3)  You require a business method that is transactional.   (For simplicity, I ignore the possibility that the document has already been locked, but you would take care of it as you do now) It would include
    
Begin Transaction 
Step A:   The execution of a find method on the Document_Lock table, determining whether or not the document is already locked.
Step B:   An update to the document entry in the Document_Lock table, setting it to lock.
Step C:   The creation of a new entry in the keyword_table, recording that the document has been locked.
Commit Transaction.  
 
4)  The preceding could be implemented in a POJO using JDBC, directly in a SSB, as an SSB invoking EB, or within an EB itself.  And I don't mean to suggest that you should use BMT if you use an EJB; the transaction statements are just there to indicate the boundary.
 
5)  The method unlocking the function works almost identically, except that you probably do not need to do the Step A find.  The client knows the record already exists because they "own" the lock.  This method could also be used by an administrator to reset individual lock entries as required.
 
Cheers,  Jim W
 
P.S.  I dimply use document, Document_Lock, etc. as an alias for a media content object, or whatever it is your are referring to with the mandant_id.

Regards,
Rafal