Hi! Im just sitting here and examining the sourcecode (even more :) and some questions popup...
I have found the PersistenceBrokerServlet and was examining how one could go about realizing such a "beast" in a Stateless SessionBean, but I quickly found that this is actually not what I want to have in my scenario :) I do not want to have the "raw" PersistenceBroker interface on to the client and I do not like to have the persistencelayer do things the J2EE container should do for me :) (e.g. loadbalancing and global cache issues) I would much rather have a sessionbean on which I could have create, read, update and delete vanilla java object and objects - and on this sessionbean place e.g. my own securitylayer. Is this possible to do safely when I only want the J2EE (and hereby JDBC and hopefully also OJB's) transaction to cover one single method. e.g. If a client have a sequence of calls: read(x), read(y), read(z), update(x,y,z) then each method has its own transaction. Does the ODMG implementation remember forever that a client has read an object ? What if this client disconnects abruptly ? When is the readlock released ? Will the update(x,y,z) succeed if the first line in that method just tries to aquire a writeLock before it call store ? Can I enable optimistic locking and then have the advantage from both worlds ? e.g. ensure consistency across threads AND be notified if someone have read/write'd before my update succeeds ? And what will happen when my application starts to use J2EE clustering ? Will the ODMG locks that is stored in the database save me ? e.g. there will be no need for a distributed cache ? /max -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
