The best advice I can give here is, run Jonas under an IDE debugger and step through the code. By setting breakpoints in your bean implementation and then stepping back out into the generated code / Jonas source, you can quickly understand what is going on. I recently had a situation where I became convinced that Jonas wasn't calling ejbStore correctly - in fact it turned out to be my fault. As well as the "modified" flag, I have a "read-only" flag which can be used to make an EJB read-only (the isModified method looks at both flags when deciding what to return). I wasn't clearing it in ejbActivate(), which meant that a reused EJB instance that had previously been used for a read-only EJB was also read-only. Joe -----Original Message----- From: Simon Oldeboershuis, outermedia [SMTP:[EMAIL PROTECTED]] Sent: Thursday, November 23, 2000 5:17 PM To: [EMAIL PROTECTED] Subject: Re: Persistency with TX_NOT_SUPPORTED ??BUG?? Hi Joe, first of all, I am wondering if I have to use the isModified() at all. I am setting the modified flag in the called business method... BUT the ejbStore() is never called and therefore the isModified is never checked. I am looking on the trace output with trace level all and level 15 and have never seen any output from ejbStore(); On the server side I am keeping the EJBBean stored in a kind of generator bean and I am not releasing it before the server is shutdown. But even in that case, the bean is not passivated correctly because the data is not stored. The create is doing OK! Everything is written to the db. I am getting a kind of convinced that this is a BUG!!! I don't know what I could do next. I pasted the trace of Jonas after I am calling the business method: --------------copy ----------- JOnASSequenceRemote.getValueAfterIncrementingBy() JBeanEntity.preinvoke setThreadData NamingManager: setComponentContext: Sequence JContainerImpl.checkTransactionIn Transaction Attribute = TX_NOT_SUPPORTED JBeanEntity.getContext: null getICtx IH JBeanEntity.postinvoke doPostInvoke resetThreadData NamingManager: setComponentContext: reset to null JBeanEntity.releaseContext releaseICtx IH sending_reply() : creates reply context null security context sets to default. sending_reply() : creates reply context principal : name = JOnAS_client --------------paste ----------- I would appreciate any hint! simon Joe Gittings schrieb: > > Simon, > > Are you remembering to set isModified()'s flag in getValueAfterIncrementing()? > > Joe > > -----Original Message----- > From: Simon Oldeboershuis, outermedia [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, November 23, 2000 2:34 PM > To: [EMAIL PROTECTED] > Subject: Persistency with TX_NOT_SUPPORTED > > Hi, > > we are using MySQL and there the transaction TX_NOT_SUPPORTED > > In the application we are using an cmp entity bean for a kind of > sequence number. The sequence number is stored in a database table. To > receive a new sequence number a business method > getValueAfterIncrementing() > is called. In this method the value of the bean is increased. BUT this > value is never saved to the database. Actually, the ejbStore() method is > never called. > > I tried to add a isModified => nothing is stored > > I tried to add a > <passivation-timeout>5</passivation-timeout> > => nothing is stored > > Does anybody know if I am doing something wrong or if this is a BUG?? > > simon << File: sol.vcf >> << File: sol.vcf >> ---- To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "unsubscribe jonas-users". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
