If you setup TIBCO EMS Queues (via JMS) with the right JMS acknowledgement mode then a GeoEvent Processor input is configured to recieve off of the JMS queue will consistently receive the event. If the input happened to fail in the process of receiving the JMS message it would be unacknowledged and put back on the Queue for it, or another GeoEvent Processor instance, to process again. If your JMS broker supports it and you desire it you could also setup max # of reattempts and idle time between attempts.
GeoEvent Processor cannot support transactions after the point the input has recieved the event and submitted it for processing by GeoEvent Services. This is due to the fact that there may be multiple GeoEvent Services listening to the input and those GeoEvent Services may have processing steps that change the event (i.e. field enricher, field calculator, etc...). Also, once the processing is complete there may be multiple outputs that the events get routed to. Defining the boundary of where a transaction would start and end in this type of environment is very challenging to do and would most likely have a negative impact on performance. For these reasons, by design, at the 10.2 release GeoEvent Processor does not support transactions. If this is an important capability for you please submit the idea on the Esri ideas site and we will consider it for a subsequent release if there is enough customer demand.
Hope this information is helpful,
ArcGIS GeoEvent Processor for Server - Product Lead