[JBoss Seam] - Creating several objects in one transaction.
by breako
Hi,
I have a simple XHTML page which is a form for a Person object.
I have a create button which will persists the Person and a commit button which commits the EntityManager by calling the appropriate methods on a Seam backing bean.
My backing bean has a Person object reference which the XHTML form refers to.
XHTML form...
|
| <table>
|
| <tr>
| <td>Your name:</td>
| <td>
| <s:decorate>
| <h:inputText value="#{person.name}" size="15"/>
| </s:decorate>
| </td>
| </tr>
|
| <tr>
| <td>Your age:</td>
| <td>
| <s:decorate>
| <h:inputText value="#{person.age}" size="15"/>
| </s:decorate>
| </td>
| </tr>
|
| <tr>
| <td>Email:</td>
| <td>
| <s:decorate>
| <h:inputText value="#{person.email}" size="15"/>
| </s:decorate>
| </td>
| </tr>
|
| <tr>
| <td>Comment:</td>
| <td>
| <s:decorate>
| <h:inputTextarea value="#{person.comment}"/>
| </s:decorate>
| </td>
| </tr>
|
| </table>
|
| ...
|
| <h:commandButton type="submit" value="Persist"
| action="#{manager.persist}"/>
|
| <h:commandButton type="submit" value="Commit"
| action="#{manager.commit}"/>
|
|
I want to create many persons in the one form. so I want something like this to happen
1. User enters person data
2. User hits persist
3. Person is persisted
4. Form is cleared, User enters data for second person
5. User hits persist
6. Person 2 is persisted
7. User hits commit
8. Person1 and Person2 are committed.
Right now I can't do this. the same Person object is always used so Person2 simple wips Person1 and only one Person gets sent to the DB.
Fair enough, as I have only one Person object in backing bean.
I was thinking of using a List but then how does the FORM know which element to refer to?
The only way I can think of doing this is by using a separate Person reference in the backing bean. So that when persist() is invoked, the current Person is copied and then persisted such as this:
|
| @Begin(join=true, flushMode=FlushModeType.MANUAL)
| public void createPerson() {
|
| Person tempPerson = new Person();
| tempPerson.setId(person.getId());
| tempPerson.setName(person.getName());
| tempPerson.setAge(person.getAge());
| tempPerson.setEmail(person.getEmail());
| tempPerson.setComment(person.getComment());
| em.persist(tempPerson);
| }
|
| @End
| public String commit () {
| em.flush();
| }
|
I think I am doing some of unnecessary work here and I was wondering would someone have a smarter idea?
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115929#4115929
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115929
17 years
[Installation, Configuration & DEPLOYMENT] - Re: JBOSS Stop error
by harish73
Now to see if this issue happen in earlier version, I have installed jboss-4.0.2 and when i start and then stop using shutdown.sh script it successfully shutdown the jboss server.
But same thing is not happeing with jboss-4.2.2.GA version.
I see below when i start jboss-4.0.2 :-
10:14:20,446 INFO [Server] Core system initialized
10:14:23,439 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resource:log4j.xml
10:14:23,552 INFO [WebService] Using RMI server codebase: http://localhost:8083/
10:14:23,876 INFO [NamingService] Started jndi bootstrap jnpPort=1099, rmiPort=1098, backlog=50, bindAddress=/0.0.0.0, Client SocketFactory=null, Server SocketFactory=org.jboss.net.sockets.DefaultSocketFactory@ad093076
10:14:29,585 INFO [SnmpAgentService] SNMP agent going active
10:14:30,706 INFO [DefaultPartition] Initializing
I see below when i start jboss-4.2.2.GA :-
09:44:47,015 INFO [Server] Core system initialized
09:44:51,369 INFO [WebService] Using RMI server codebase: http://localhost:8083/
09:44:51,377 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resource:jboss-log4j.xml
09:44:52,553 INFO [TransactionManagerService] JBossTS Transaction Service (JTA version) - JBoss Inc.
09:44:52,554 INFO [TransactionManagerService] Setting up property manager MBean and JMX layer
09:44:53,004 INFO [TransactionManagerService] Starting recovery manager
09:44:53,197 INFO [TransactionManagerService] Recovery manager started
09:44:53,197 INFO [TransactionManagerService] Binding TransactionManager JNDI Reference
09:44:58,622 INFO [EJB3Deployer] Starting java:comp multiplexer
09:45:01,106 INFO [STDOUT]
If you see from both output "NamingService" is not started in jboss-4.2.2.GA.
Is this could be the issue?? Yes, which file i have to do the changes?
Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115928#4115928
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115928
17 years
[JBossCache] - Buddyrep issue
by FredrikJ
Hi.
I am currently using cache 2.1.0 GA and jgroups 2.6.1 with buddy replication. Buddy rep is configured to use one buddy only.
The setup is four nodes with ip addresses like:
172.16.0.5
| 172.16.0.6
| 172.16.0.7
| 172.16.0.8
|
| They are all started in the stated order so that .5 is the coordinator. The first node up (.5) will insert data to the cache and then data will gravitate to the other nodes when needed. This will occur mostly initially when applying load to the system. Data affinity is handled by a layer above the cache.
|
| Using this scenario with 2.0.0 GA presented no problems except adding new nodes during load, so we are now investigating 2.1.0.
|
| The issue I'm facing is that the coordinator seems to get two buddy backups, one being itself.
|
| This is the contents on 172.16.0.5 (coordinator):
|
|
| | null {}
| | /91 {91=com.cubeia.firebase.game.table.InternalMetaData@1134d9b com.cubeia.testgame.server.game.TestGame@1cdc8ce}
| | /63 {63=com.cubeia.firebase.game.table.InternalMetaData@cc9ff5 com.cubeia.testgame.server.game.TestGame@951aeb}
| | /92 {92=com.cubeia.firebase.game.table.InternalMetaData@e60a39 com.cubeia.testgame.server.game.TestGame@185c84e}
| | ...
| |
| | /_BUDDY_BACKUP_ {}
| | /172.16.0.8_8786 {}
| | /15 {15=com.cubeia.firebase.game.table.InternalMetaData@d9e1c0 null}
| | /16 {16=com.cubeia.firebase.game.table.InternalMetaData@742062 null}
| | /172.16.0.5_8786 {}
| | /31 {}
|
| Notice that there are two members listed under_BUDDY_BACKUP, one is .8 and the other one is .5, which is itself.
|
| Now, on 172.16.8 we get a lot of lock timeouts like the one below:
|
| Caused by: org.jboss.cache.lock.TimeoutException: read lock for /_BUDDY_BACKUP_/172.16.0.5_8786 could not be acquired by GlobalTransaction:<172.16.0.6:8786>:41 after 5000 ms. Locks: Read lock owners: []
| | Write lock owner: GlobalTransaction:<172.16.0.6:8786>:1
| | , lock info: write owner=GlobalTransaction:<172.16.0.6:8786>:1 (activeReaders=0, activeWriter=Thread[Incoming,TableSpace,172.16.0.8:8786,5,Thread Pools], waitingReaders=25, waitingWriters=0, waitingUpgrader=0)
| |
|
| 172.16.0.8 also shows two members under the buddy backup:
|
| null {}
| | /28 {}
| | /29 {}
| | /92 {}
| | ...
| | /_BUDDY_BACKUP_ {}
| | /172.16.0.7_8786 {}
| | /91 {91=com.cubeia.firebase.game.table.InternalMetaData@1fbeed6 null}
| | /41 {41=com.cubeia.firebase.game.table.InternalMetaData@fd3922 null}
| | /115 {115=com.cubeia.firebase.game.table.InternalMetaData@b215d9 null}
| | ...
| | /172.16.0.5_8786 {}
| | /31 {}
| |
|
| It seems like .8's buddy to backup is in fact .7. But we still hold some buddy ref to the .5 member as well. In fact, all the lock timeouts on .8 is related to to .5 buddy back fqn:
|
| failure acquiring lock: fqn=/_BUDDY_BACKUP_/172.16.0.5_8786
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115924#4115924
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115924
17 years